Re: [rtl] Networking in realtime? Trying low latency...

[David Olofson]

Mon, 14 Aug 2000 Wilken Boie wrote:
> David,
> 
> many thanks for your comment. The issue has kept me busy over the
> weekend and I found the mentioned links already. They supplied 
> exactly the proper info and tools.
> 
> I applied the latest matching patch I found (lowlatency-2.2.14-B1 for my
> RTAI 1.3 on Linux 2.2.14). The results are remarkable (~1-2 ms latency). 
> Though unfortunately the system became unstable (X freezes and the rest 
> goes mad as well after a while).

Not fun...

> So I'm wondering if anybody knows about a 
> 
> successfull combination of hard realtime and low latency patches

Unfortunately, I don't have much personal experience with the latest versions.
Currently, I'm running an X/KDE workstation on 2.2.10/lowlatency, which is rock
solid, and has never caused problems here. However, I have used the same kernel
at home, where it occasionally freezes if (or rather; when...) I get kicked
from the PPP/modem connection. No other problems. I haven't tried adding RTL or
RTAI to this lowlatency kernel yet.

As for later lowlatency versions, I've tried the precompiled image available at
Benno's site, and that worked perfectly on my machine at home. However, as it
isn't configured the way I like it, I tried to patch up an identical source
tree - but the kernel I built from that get very unstable when stressing the
system. Any "normal" applications (including my lowlatency audio stuff) worked
great, but Benno's latencytest (which does X stress, disk stress etc) made the
machine freeze early in the test. 100% reproducable, same spot. Haven't had
time to investigate it further yet.

> So I'm wondering if anybody knows about a 
> 
> successfull combination of hard realtime and low latency patches
> 
> or has experience related to combining the two (I hope some of the
> people you mentioned listen). 

You could perhaps post on LAD (Linux-Audio-Dev) - some of the people around
there have experience with RTL, RTAI and other solutions, and there might be
someone there who is using RTL + lowlatency on a regular basis. (I would
expect to find most RTL users on this list, but...)

Anyway, I don't think the two patches should interfere with each other on the
functional level - the lowlatency patch basically adds conditional reschedule
points in areas where the kernel can stay for too long, while RTL entirely
bypasses Linux on the IRQ level. (IFAIK, you don't even need a kernel patch to
run RTL on PPC, as that kernel has a "pluggable" HAL layer in the standard
version, as opposed to x86, which inlines STI/CLI instructions.)

> I think this could nicely cover a range of problems where hard realtime 
> is too restricted (or causing too much efforts, e.g. network related) 
> and soft realtime (wich just turned out to be too slow).

Actually, although you *can* do "RT unsafe" operations from within SCHED_FIFO
threads under Linux/lowlatency, that breaks the hard RT timing. As far as tests
show (*), Linux/lowlatency is very reliable as to peak latency, but of course,
the basic rules of RT programming still applies; you don't get hard RT if you
rely on *any* services that do not have bounded response time.

(*) Linux/lowlatency is way more complicated than a real RT kernel such as RTL
or RTAI, which means that it's practically impossible to specify a 100%
reliable maximum scheduling latency. For a simpler kernel, you could (at
least in theory - or at NASA) analythically specify the absolute maximum
number of cycles that any RT operation may take, but the complexity of such
an analyze explodes as the amount of code increases. The only practically
possible way to verify the reliability of Linux/lowlatency is to
stress-test machines. This has been done, and the systems we consider
working have been tested for days under high system stress without ever
missing a deadline.

As long as you're dealing with hard RT, the differences between RTL and
Linux/lowlatency are basically

lowlatency  RTL

Protected memoryyes no(*1)
SecurityNormal(*2)  None (*3)
Worst case latency  <1 ms   <50 µs
Use standard driversyes no
Direct syscalls yes no
All syscalls RT safeno  no

(*1) Available through RT signals

(*2) It's possible to a) have a system daemon promote normal applications to
 SCHED_FIFO scheduling, so that they never need root privileges, and b)
 throw in a watchdog thread that keeps these applications from freezing the
 system. Root access is only required for *setting* SCHED_FIFO - not for
 using it.

(*3) May not be true if the signal handlers can be in non-root programs. A
 watchdog would be required just as for lowlatency, so that these handlers
 cannot freeze the system indefinitely.

> I may well be wron

Re: [rtl] Flood Pings on underpowered processors

[eric]

The script kiddies have any number of such tools available to them.  Do
a google search for 
hackerz, ping of death, syn flood, etc.  I only tell you this because if
you were a prospective script kiddie yourself, you would have signed
your name jOhN jEffErZ
eric


John Jeffers wrote:
> 
> Hello
> 
> Has anyone developed a piece of test code to try and render unresponsive a
> networked device by creating flood pings / "all call" packets.  If so is
> the source code available / or what was done to test a network device
> against such a issue.
> 
> My information is a network with a NT server is especially likely to
> produce such packets and has caused some embedded devices to fail due to
> processor starvation by servicing non-stop packet interrupts.
> 
> Any opinions of this?  It has been indicated to me that companies have seen
> this before and this is a situation that needs to be tested for. (although
> this problem is bad networking form)
>
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

No Subject

[joseph canou]

hello
i try to read data on a high speed serial port (moxa card at
500k bauds)
to do that i only use the outb and inb functions in my
module
i store 732 values in a table (unsigned char donnee[732])
when i have this 732 values i make a rtf_put() to be able to
read this data in my main program
in my cleanup() i make a vfree(donnee)

when my program try to stop the task i have this message and
there is a segmentation error and i can't rmmod my module



Unable to handle kernel paging request at virtual address
8b20c483
current->tss.cr3 = 0de17000, %cr3 = 0de17000
*pde = 
Oops: 
CPU: 0
EIP: 0010:[]
EFLAGS: 00010246
eax:  ebx: fffe ecx:  edx:

esi: d082f83c edi: 8b20c483 ebp:  esp:
cdfa5f5c
ds: 0018 es: 0018 ss: 0018
Process lsmod (pid: 696, process nr: 40, stackpage=cdfa5000)
Stack: ba10 cdfa5fb0 fffe d082c000 8b20c483 
cc359000 cc359000
 0200 c0115bd1 d082c000 0804a5c8 0400 ba10
cdfa4000 0400
 ba10 0804a5c8 cdfa4000 0010 40014000 cc359000
cdd4e000 c022e800
Call Trace: [] [] []
[]
Code: f2 ae f7 d1 49 8d 59 01 3b 5c 24 38 77 48 83 c4 fc 53
8b 44

i think Code are the data i want to read but that's the only
thing i understand

thank you for your help
__
Boîte aux lettres - Caramail - http://www.caramail.com

[rtl] Flood Pings on underpowered processors

[John Jeffers]

Hello

Has anyone developed a piece of test code to try and render unresponsive a 
networked device by creating flood pings / "all call" packets.  If so is 
the source code available / or what was done to test a network device 
against such a issue.

My information is a network with a NT server is especially likely to 
produce such packets and has caused some embedded devices to fail due to 
processor starvation by servicing non-stop packet interrupts.

Any opinions of this?  It has been indicated to me that companies have seen 
this before and this is a situation that needs to be tested for. (although 
this problem is bad networking form)

Regards John

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

[rtl] ioremap problem

[Frederic Cazenave]

Hi,

I try to port a DOS program under rtl but I've a problem to map a pci
memory :

On my pci acquisition board I've got 0x2 bytes of DPRAM, 0x4
bytes for a table, 0x20 bytes for Timer and 2 for a status register.

under /proc/pci I can see the physical adress of this four regions :

   Bus  0, device   9, function  0:
  Keyboard controller: AMCC Unknown device (rev 0).
  Vendor id=10e8. Device id=5920.
  Medium devsel.  Fast back-to-back capable.  IRQ 10.
  I/O at 0xf000 [0xf001].
  Non-prefetchable 32 bit memory at 0xffac [0xffac].
  Non-prefetchable 32 bit memory at 0xffabffc0 [0xffabffc0].
  Non-prefetchable 32 bit memory at 0xffabffb0 [0xffabffb0].
  Non-prefetchable 32 bit memory at 0xffa0 [0xffa0].

when I init my module I request this regions like this :

int init_piraq(void)
{
  u32 val;
  struct pci_dev * dev = NULL;

  printk("\nStarting Real Time Piraq II module\n");
  dev = pci_find_device(PIRAQ_VENDOR,PIRAQ_ID, dev);
  if (dev == NULL) {
printk("No Piraq board installed\n");
return (-1);
  }

  pci_read_config_dword (dev,0x20,&val);
  LOOKUP =  ioremap(val,(u32)0x4);
#ifdef DEBUG
  printk("@LOOKUP = 0x%x %x\n",LOOKUP,val);
#endif
  if(check_region(*LOOKUP,0x4)) {
printk("Piraq Lookup Table is locked by someone else\n");
  }
  request_region(*LOOKUP,0x4,"PII_lookup");

  pci_read_config_dword (dev,0x14,&val);
  PII_DPRAM = ioremap(val,(u32)0x2);
#ifdef DEBUG
  printk("@DPRAM = 0x%x %x\n",PII_DPRAM,val);
#endif
  if(check_region(*PII_DPRAM,0x2)) {
printk("Piraq Dpram is locked by someone else\n");
  }
  request_region(*PII_DPRAM,0x2,"PII_dpram");

  pci_read_config_dword (dev,0x18,&val);
  TIMER = ioremap(val,(u32)0x40);
#ifdef DEBUG
  printk("@TIMER = 0x%x %x\n",TIMER,val);
#endif
  if(check_region(*TIMER,0x40)) {
printk("Piraq Timer is locked by someone else\n");
  }
  request_region(*TIMER,0x40,"PII_Timer");

  pci_read_config_dword (dev,0x1C,&val);
  STATUS =  ioremap(val,(u32)0x02);
#ifdef DEBUG
  printk("@STATUS = 0x%x %x\n",STATUS,val);
#endif
  if(check_region(*STATUS,0x02)) {
printk("Piraq Status is locked by someone else\n");
  }
  request_region(*STATUS,0x02,"PII_Status");
}

All the printk provide the following result :

Aug 15 20:36:58 kernel: Starting Real Time Piraq II module
Aug 15 20:36:58 kernel: created RT-thread
Aug 15 20:36:58 kernel: @LOOKUP = 0xc2a5a000 ffa0
Aug 15 20:36:58 kernel: Piraq Lookup Table is locked by someone else
Aug 15 20:36:58 kernel: @DPRAM = 0xc2a9b000 ffac
Aug 15 20:36:58 kernel: @TIMER = 0xc2abcfc0 ffabffc0
Aug 15 20:36:58 kernel: @STATUS = 0xc2abefb0 ffabffb0
Aug 15 20:36:58 kernel: Piraq II board found at 0xf001 interrupt 0xa

Under /proc/ioports I can see all my request except the one for the
LOOKUP.

If I decrease the size of the LOOKUP to some thing very small I can
make the request.

Do you have any solution 

I can allocate all the LOOKUP size with djgpp.

Thank in advance

Fred Cazenave

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] Networking in realtime? Trying low latency...

[Wilken Boie]

<<< 
  PLS excuse, if this mail appears again. But on my account it didn't
  show up within two days. So I'm afraid it did not get thru.
>>>

David,

many thanks for your comment. The issue has kept me busy over the
weekend and I found the mentioned links already. They supplied 
exactly the proper info and tools.

I applied the latest matching patch I found (lowlatency-2.2.14-B1 for my
RTAI 1.3 on Linux 2.2.14). The results are remarkable (~1-2 ms latency). 
Though unfortunately the system became unstable (X freezes and the rest 
goes mad as well after a while).

So I'm wondering if anybody knows about a 

successfull combination of hard realtime and low latency patches

or has experience related to combining the two (I hope some of the
people you mentioned listen). 

I think this could nicely cover a range of problems where hard realtime 
is too restricted (or causing too much efforts, e.g. network related) 
and soft realtime (wich just turned out to be too slow).

I may well be wrong, but I understand that RTAIS's LXRT would suffer
from the same problem: either I am in (restricted) hard realtime or 
encounter (unacceptable) latencies while in soft realtime.

Wilken



> Wilken Boie wrote:
> > ...
> > I tried to follow the advice given many times: trigger a user space
> > helper (I'm using /dev/rtf0). My helper thread blocks on reading
> > a byte written by a RTAI module ervery 20ms and then sends some data.
> >
> > My aim is to send a udp broadcast as closely bound to that trigger as
> > possible. Jitter would be well acceptable up to 1+ ms. I assumed to
> > achieve that by setting the helper thread to SCHED_RR with a high
> > priority (e.g. 99).
> >
> > But I find this construct working quite precise only most of the time:
> >...
> 

David Olofson wrote:
> 
> Indeed, this is to be expected from the soft real time scheduling provided
> by SCHED_RR or SCHED_FIFO. (BTW, you should usually use SCHED_FIFO for this
> kind of stuff, unless you have multiple RT threads that will use lots of CPU
> time.) As opposed to RTL, it's not *hard* real time.
> 
> However, it is possible to get worst case latencies in the ms range with Ingo
> Molnar's lowlatency patch. I think some people have succeded in applying
> some versions of lowlatency and RTL together, which allows the great
> combination of kernel drivers with µs timing and user space code with ms
> timing. Have a look at:
> 
> http://www.gardena.net/benno/linux/audio/
> 
> http://www.crosswinds.net/~linuxmusic/lowlatency.html
> 
> Another alternative (which should provide significantly lower latencies) would
> be the new hard RT signals from RTL. (Still beta, AFAIK.) I believe RTAI has
> had a similar feature for some time.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] Cheapest RTLinux platform ?

[Peter Staudt]

Hi Johan,

> Johan Stenfors wrote:
> 
> I want to eveluate RTlinux for small devices, but run into 
> problem with expensive hardware. The CPU cards available for 
> intel processors normally cost more than a new stripped PC, and I 
> expect lower price than that.
> 
> Can anyone give a hint of a cheap platform for this. The cpu does 
> not matter as long as it can run a linux system. Even system 
> designs that can easily be build "by hand" are of interest.
> 
> If evaluation systems with serialport and perhaps IDE interface 
> are available at a low cost that would be perfect.
> 
Maybe you find something appropriate at .
Their boards run with Linux and they have really small ones.

HTH, Peter
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

[rtl] 2.4.0-test6 and rtlinux version

[Robert Kavaler]

I have two questions:

1. What is the next 2.4.0 that will have an rtlinux patch (i.e. test6?)?

2. How does one determine the RTLinux version (i.e. 3.0).  Now that RTLinux
versions do not correspond to Linux versions, there are some features that need
to be #defined based on RTLinux version, not Kernel version.

Robert Kavaler
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

[rtl] Is there a port of RTLinux on QED RM 52xx

[Jithendranadh]

 
Hi,
 
Is there a port of 
RTLinux available on QED RM 5231 or 5271 (MIPS) processor?
 
jithu