Hi Sebastian, thanks for the feedback. > > I run the cyclictest with the following options: > > # cyclictest -a -i 100 -d 10 -m -n -t -p 80 > > there is -S. And then 100 might be a little tight. > > > Of course the 2 minutes run-time of cyclictest is only a rough first estimate. > > and with no load… > > > Once I configure one of the i350 ports # ifconfig eth2 up > > 192.168.100.100 the cyclictest shows directly and reproducibly > > significant larger max latency values (40 microseconds, using the same > conditions). > > > > > > I did the very same test with kernel version 3.18.27-rt27. > > With that version I did not see anything like that. > > > > Also, only the igb driver seems to cause the trouble. I have also an > > e1000e based NIC in this PC and the usage of this driver does not add any > significant latency. > > > > Any idea on this? > > Does this also happen if you have the NIC up and you plug in / out the cable? There > are two things that come to mind: > https://lkml.kernel.org/r/1445465268-10347-1-git-send-email- > jonathan.david@xxxxxx > https://lkml.kernel.org/r/1445886895-3692-1-git-send-email-joshc@xxxxxx This happens even if I have done "ifconfig up" on the NIC without having a cable plugged in. Also, it happens if I have a cable plugged in and the link is up but no traffic is running via this NIC port. It looks as if solely the configured NIC port is causing the additional latency, no matter if traffic is flowing via this NIC or not and no matter if the link is up or not. I did the same test with the kernel/rt_preempt patch versions 4.1.33-rt37 and 4.4.19-rt27, they show the very same behavior. In opposite to that, the version 3.18.27-rt27 is working stable! As mentioned before, the "igb" driver is causing the issue. The "e1000e" driver works fine. Best regards Mathias ��.n��������+%������w��{.n�����{�����ǫ���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
