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] Rx CRC errors
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 signature.asc Description: OpenPGP digital signature -- 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
Re: [RTnet-users] r8169 / rtl8168/ 8111 driver
On 2012-10-11 08:40, Stéphane ANCELOT wrote: 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. I'm willing to merge patches to fix the existing driver or replace it with something better, but no longer carry drivers with overlapping support. The E1000 mess was already painful enough (still need to decide on the E1000-new). Looking at the diff and the age of the rt_r8169, reviewing, fixing and testing your driver may be the better option. However, from a first glance: - rtdm_irq_disable/enable is fishy, can you explain its need? - rtl8169_tx_timeout - schedule_work is called from RTDM IRQ context - rtl8169_start_xmit leaks a lock on error So there is some work remaining to make it ready for upstream. As I have test hardware around, I can help with validating the 8169 case. Jan signature.asc Description: OpenPGP digital signature -- 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] Useful way to measure bandwidth?
Hi Michael, On 10/09/2012 12:15 PM, Michael Morscher wrote: Hi there, What is the best way to measure the bandwidth between two RT Nodes? I've a setup running two clients and as I'm playing with configuration values for window sizes etc. I need a way to measure the available bandwidth. ( to get a better understanding/tuning for my project) I would take a simple network benchmark program, e.g. ttcp and port it to RTnet. Should not be a big deal, think. Tried the known ways like iperf but actually I think the produced traffic is encapsulated and not send at its optimum. So I only get something between 2 and 6 Mbit/s on E1000 driver/PCI cards which is not what I need. What protocol do you use? Wolfgang. -- 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
