[RTnet-users] encapsuling packets (ethernet over ethercat)
Hi, I am thinking about an implementation I need, and I am not sure which way will be the best . 1/ I need to catch tcp/ip packets routed from non realtime nic eth0 . 2/ I encapsulate the tcp/ip frames in the final protocol and send the frame request to rteth0 (realtime) 3/ I will receive reply on realtime rteth0 s. I will then remove encapsulation from this frame and send it back to non realtime net through eth0. In this scenario, I will need routing in rtnet stack ? I don't want to manage ARP messages. Do I need tun/tap interface ? ETH0 === Encapsulating packet with an application === RTETH0 reply : RTETH0 = removing encapsulation = ETH0 Regards, Steph -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Update rt_e1000e driver -- job offer
Hi, There are so many reasons that could happen. At first, are you sure , your xenomai system has not any jitter involved ? And how have you checked it ? Regards, S.Ancelot On 26/05/2014 11:16, Mariusz Janiak wrote: Dear all, We are looking for a person who is able to update the rt_e1000e driver to make it supporting the newer Intel NIC like 82574L, 82579LM, 82567V correctly under the Xenomai 2.6.3 with a kernel at least 3.8.13 or newer. The problem is following, while RTnet modules and drivers load correctly without any warnings, NIC is not able to send ethernet frames for some random time. During that time, RTnet stack report that is not able to transmit synchronization frame (TDMA: Failed to transmit sync frame!), the rt_e1000e driver reset device several times, and two leds integrated with connector are not blinking. After a while, device start to operate normally, sync frame are sending normally, and there is no further issues. The main problem is, that we don't know when RTnet stack start to work, so we have to wait unpredictable period of time. Also just after NIC start sending sync frames, it has buffered several old ones, so it send them one ofter another as fast as possible, what make problem for our custom devices during synchronization phase. Currently, we observe similar non acceptable behavior on following machines: - Supermicro MBD-X9SPV-M4-3QE-O, - Advantech PCM-3363D-1GS8A1E, - Commel Mini-ITX Motherboard LV-67C. with latest RTnet git version, Xenomai 2.6.3, kernel 3.8.13 and Ubuntu 12.04. We expect that an involved person should prepare a patch which remove described issues and applies cleanly to the latest RTnet git version. The patch should be available for a community on the same license as RTnet stack. Patch will be tested on listed devices. We offer a contract to perform a specified task, one of the parties will be Wroclaw University of Technology Wybrzeże Wyspiańskiego 27 50-370 Wrocław tel. 71 320 26 00 NIP: 896-000-58-51 REGON: 01614 www.pwr.edu.pl Please send your letter of application including, short CV, expected salary (EUR or PLN) and estimated time period required for patch preparation, to Mariusz Janiak Chair of Cybernetics and Robotics, Wroclaw University of Technology Janiszewskiego 11/17, Wroclaw, Poland, tel: +48 71 320 26 44 email: mariusz.jan...@pwr.edu.pl Best regards, Mariusz -- The best possible search technologies are now affordable for all companies. Download your FREE open source Enterprise Search Engine today! Our experts will assist you in its installation for $59/mo, no commitment. Test it for FREE on our Cloud platform anytime! http://pubads.g.doubleclick.net/gampad/clk?id=145328191iu=/4140/ostg.clktrk ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users -- The best possible search technologies are now affordable for all companies. Download your FREE open source Enterprise Search Engine today! Our experts will assist you in its installation for $59/mo, no commitment. Test it for FREE on our Cloud platform anytime! http://pubads.g.doubleclick.net/gampad/clk?id=145328191iu=/4140/ostg.clktrk ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Rx CRC errors
On 11/10/2012 06:56, Jan Kiszka wrote: Regarding the drivers, the existing interface should be used (or implemented where lacking yet). Regarding a userspace interface, we only have /proc/rtnet/stats so far. Would that be sufficient for your use case, or how does you userspace need to access the data? I would need a straight access to these data, it seems cleaner using an ioctl to poll it periodically , from the userspace app. I think this ioctl should be implemented in any RTNET driver. Regards, S.Ancelot -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] r8169 / rtl8168/ 8111 driver
Hi, This driver has been derived from the 2.6.34 vanilla kernel. 2 years ago, there was a lack with 8168 support in existing rt_r8169 driver, from our viewpoint there was more added value porting the vanilla kernel one, and if I remember some caveats with MSI interrupts. I think you should not replace the existing rt_r8169 driver, but use it as an additional driver for 8111/8168 , it should also drive r8169 , but I have not tried it. I am running this driver for more than 2 years, without any problems (but I agree, only one target platform). The improvements needed are regarding driver's behaviour in a bad network context (equipment failure, connection problems, and so on), but this is a general feature and is not only related to this driver, and may depend on your application. Regards, S.Ancelot On 11/10/2012 06:57, Jan Kiszka wrote: On 2012-10-10 14:28, Stéphane ANCELOT wrote: Hi everybody ! You can use the following RT net driver for r8169 / 8168 / 8111 Thanks for sharing, but how does this relate to the existing rt_r8169? Can't the latter be augmented, if required, to fulfill your needs? Would be preferred. Jan I know it is working fine for r8111/8168 component we are using. The file is enclosed. Regards, S.Ancelot -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Rx CRC errors
The reason why I would need this is as follow : One equipement begins to fail, and I receive frames with CRC errors The driver is able to watch it, not the application - this is a problem. Then a maintenance process comes and must be able using the driver to run a diagnosis program. use case 1: the recv function returns -1 the application checks /proc/rtnet/stats use case 2 : the application polls the nic status with an ioctl. Regards, S.Ancelot On 11/10/2012 08:26, Jan Kiszka wrote: On 2012-10-11 08:23, Stéphane ANCELOT wrote: On 11/10/2012 06:56, Jan Kiszka wrote: Regarding the drivers, the existing interface should be used (or implemented where lacking yet). Regarding a userspace interface, we only have /proc/rtnet/stats so far. Would that be sufficient for your use case, or how does you userspace need to access the data? I would need a straight access to these data, it seems cleaner using an ioctl to poll it periodically , from the userspace app. I think this ioctl should be implemented in any RTNET driver. Drivers don't expose RTDM devices. We only have RTDM sockets so far, you should would have to add something similar to the netdevice(7) interface of Linux (see man page). Jan -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
[RTnet-users] Rx CRC errors
Hi everybody ! I would need being able to retrieve crc erros in the userspace application. What would be the nicest way doing this in rtnet driver ? an IOCTL to get stats ? Is it already done in some drivers, where I could have a look at it ? Regards, S.Ancelot -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
[RTnet-users] 2 intel nic
Hi, We have got two onboard intel nics in our PC , however only on,e is recognised what are the options to allow boths ??? Best Regards Steph - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
