Re: [Emc-developers] HEADS UP: RT-preempt and network I/O/system calls from RTthreads probably not viable

2014-01-31 Thread Kenneth Lerman
On 1/31/2014 4:53 AM, Michael Haberler wrote: Am 30.01.2014 um 21:47 schrieb Charles Steinkuehler char...@steinkuehler.net: On 1/30/2014 2:14 PM, Michael Haberler wrote: Once ethernet level packet I/O is settled as fast enough, we can turn to add the minimal IP/UDP framing needed. This will

Re: [Emc-developers] HEADS UP: RT-preempt and network I/O/system calls from RTthreads probably not viable

2014-01-31 Thread Michael Haberler
Am 31.01.2014 um 15:24 schrieb Kenneth Lerman kenneth.ler...@se-ltd.com: On 1/31/2014 4:53 AM, Michael Haberler wrote: Am 30.01.2014 um 21:47 schrieb Charles Steinkuehler char...@steinkuehler.net: On 1/30/2014 2:14 PM, Michael Haberler wrote: Once ethernet level packet I/O is settled as

[Emc-developers] HEADS UP: RT-preempt and network I/O/system calls from RTthreads probably not viable

2014-01-30 Thread Michael Haberler
Michal is trying hard to get the 7i80/hm2_eth.c driver working for RT-PREEMPT using normal socket I/O from an RT thread. The hopes with RT-PREEMPT are obviously pegged on the assumption: 'the kernel is hardened, so I'm free to use any system calls from an RT thread and still get decent

Re: [Emc-developers] HEADS UP: RT-preempt and network I/O/system calls from RTthreads probably not viable

2014-01-30 Thread Lars Segerlund
It depends on the driver implementation, ie. if the kernel code is using preempt disable or disable interrupts. ALL preempt-rt performance is to a large extent dependent on the quality of the device drivers. If you look at osadl.org there is an effort on realtime device drivers ... / Lars

Re: [Emc-developers] HEADS UP: RT-preempt and network I/O/system calls from RTthreads probably not viable

2014-01-30 Thread Michael Haberler
Am 30.01.2014 um 11:42 schrieb Lars Segerlund lars.segerl...@gmail.com: It depends on the driver implementation, ie. if the kernel code is using preempt disable or disable interrupts. The kernel execution path is _much_ longer than just the driver, and depending on the system call all sorts

Re: [Emc-developers] HEADS UP: RT-preempt and network I/O/system calls from RTthreads probably not viable

2014-01-30 Thread Lars Segerlund
2014-01-30 Michael Haberler mai...@mah.priv.at: Am 30.01.2014 um 11:42 schrieb Lars Segerlund lars.segerl...@gmail.com: It depends on the driver implementation, ie. if the kernel code is using preempt disable or disable interrupts. The kernel execution path is _much_ longer than just the

Re: [Emc-developers] HEADS UP: RT-preempt and network I/O/system calls from RTthreads probably not viable

2014-01-30 Thread Michael Haberler
Am 30.01.2014 um 12:55 schrieb Lars Segerlund lars.segerl...@gmail.com: 2014-01-30 Michael Haberler mai...@mah.priv.at: Am 30.01.2014 um 11:42 schrieb Lars Segerlund lars.segerl...@gmail.com: It depends on the driver implementation, ie. if the kernel code is using preempt disable or

Re: [Emc-developers] HEADS UP: RT-preempt and network I/O/system calls from RTthreads probably not viable

2014-01-30 Thread Michał Geszkiewicz
Hi, Basic idea of making hm2_eth driver under rt-preempt was to get basic architecture up and running, there was to much 'I don't know, must test it' areas. I started to use rtnet becouse it is realtime and it is supported in RTAI and Xenomai. Unfortunately specific driver architecture (part

Re: [Emc-developers] HEADS UP: RT-preempt and network I/O/system calls from RTthreads probably not viable

2014-01-30 Thread andy pugh
On 30 January 2014 13:17, Michał Geszkiewicz mic...@wp.pl wrote: Peter has driver working for 3 weeks 24/7, Skunkworks can flashing leds and I can use sserial slave cards without breaking connection. As a rather more extreme test, I have used it software-commutation of a brushless motor, with

Re: [Emc-developers] HEADS UP: RT-preempt and network I/O/system calls from RTthreads probably not viable

2014-01-30 Thread Michał Geszkiewicz
W dniu 30.01.2014 16:38, andy pugh pisze: On 30 January 2014 13:17, Michał Geszkiewicz mic...@wp.pl wrote: Peter has driver working for 3 weeks 24/7, Skunkworks can flashing leds and I can use sserial slave cards without breaking connection. As a rather more extreme test, I have used it

Re: [Emc-developers] HEADS UP: RT-preempt and network I/O/system calls from RTthreads probably not viable

2014-01-30 Thread Michael Haberler
Am 30.01.2014 um 14:17 schrieb Michał Geszkiewicz mic...@wp.pl: So now is good time for me to follow MHaberler searching of best udp stack or layer or library to decrease this terrible overhead while reading data from 7i80. It took about 400 to 700us on each 1ms thread entry. well these

Re: [Emc-developers] HEADS UP: RT-preempt and network I/O/system calls from RTthreads probably not viable

2014-01-30 Thread Charles Steinkuehler
On 1/30/2014 2:14 PM, Michael Haberler wrote: Once ethernet level packet I/O is settled as fast enough, we can turn to add the minimal IP/UDP framing needed. This will be bare bones (no ping, arp, and other amenenities) but should have pretty much the same timing behavior and good enough for

Re: [Emc-developers] HEADS UP: RT-preempt and network I/O/system calls from RTthreads probably not viable

2014-01-30 Thread sam sokolik
I have been helping test the mesa 7i80 (ethernet). I started with the RTnet setup but what a pain. Supported nics are very limited. When micges switched to rt_preempt there was a watchdog bug that bit the 7i80 (pun intended..) but through all the testing I don't think I once got a realtime