We also had similar problems when where we face these kind of periodic jitter. In our case we used Intel 82551ER Fast Ethernet Controller( e100 driver ). The problem with ours was the with the microcode (in e100.c) of the adapter which had default algorithm where the hardware was holding of the interrupts until X packets or Y usecs have expired. This generated a periodic jitter that was 400-500 us more than the usual one. This was solved by making the hardware generate interrupt on every frame. In e100.c this can be done by changing the values of INTDELAY, BUNDDLEMAX and BUNDDLESMALL (CPU saver parameters) On 8/31/07, Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx> wrote: > Hi, > > We are currently porting a userspace realtime network stack (Ethernet > Powerlink -> EPL) to RT-Preempt, in order to play with the system and > find out what is possible today with a standard linux-rt and userspace > socket based stacks. > > We currently see a strange latency effect. The scenario is like this: > > +--------+ +-----------+ +-----------+ > | PC EPL | | Second PC | | EPL Clamp | > +--------+ +-----------+ +-----------+ > | | | > \ +----------+ / > \----| Hub |------/ > +----------+ > > EPL is a protocol where the Master (PC EPL) sends a cyclic Start-of- > Cycle packet (SoC) to the network; our cycle time is 2 ms. To make sure > we do not se effects from the stack itself, we have written a small > program which sends a packet every 2 ms via raw socket. > > We have a second PC which listens to the same network; this box takes > the packet time stamps (SO_TIMESTAMP), substracts the 2 ms cycle time > since the last SoC and plots the resulting jitter: > > http://www.pengutronix.de/software/realtime-preempt/20070831-network-jitter/epl-jitter-log-20070831-1.png > > What we see is that most of the packet times stay within something > around 10 us. However, there are periodic jitters which exceed that > period by a huge factor; in that case the jitter is in the 200...400 us > area, and notice the systematic patterns in the plots. > > The periodicity of the 200...400 us is fixed for an unchanged clock > source (18 s in this example, we have seen values up to 200 s). The > periodicy changes when the clock source is changed in > > /sys/devices/system/clocksource/clocksource0/current_clocksource > > Changing to another clock source and changing back changes the period, > but it is not reproducable if you change back to the same source (hpet, > acpi_pm, tsc). There is also no visible corellation between the concrete > clocksource and the period. > > The periodicity is fairly precise, it varies with < 5 us. > > Has anyone seen a similar effect? > > Robert > -- > Pengutronix - Linux Solutions for Science and Industry > Entwicklungszentrum Nord http://www.pengutronix.de > - > To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Thanks Giri - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
