LinuxCNC, latency test i duże czasy

Witam.
od jakiegoś czasu używam do sterowania maszynami CNC programu linuxCNC.
Na pierwszej maszynie miałem komputer:
HP Compaq nc6000
Intel Pentium 1600 MHz
2GB RAM
linuxCNC śmigał aż miło.
Na drugiej miałem
Fujitsu LifeBook E8410
Intel Core 2 Duo T7500 - 2,20 GHz
2 GB RAM
Też wszystko w porządku.
Do następnej maszyny kupiłem laptop:
DELL E6400 ze stacją dokującą aby mieć LPT.
Procesor Intel® Core™2 Duo P8600 pamięć podręczna 3 MB, 2,40 GHz, FSB 1066 MHz
2GB RAM

I jest problem.
Komputer według moich wrażeń śmiga bardzo ładnie i płynnie, natomiast latency test daje wynik nawet do 350000ns jeśli nic nie robię na komputerze.
Po uruchomieniu linuxCNC pojawia się komunikat błędu (nie zapisałem niestety jaki) ale coś na temat błędu z uzyskaniem sterowania czasu rzeczywistego.

Czy ktoś ma jakieś doświadczenia w tym temacie? Z pozoru komputer nie gorszy od poprzedników a coś nie gra.
Jakieś ustawienia w biosie? Czego szukać, na co zwrócić uwagę.
Komputer zakupiłem i uruchomiłem wczoraj, dziś rano idę do pracy i chciałbym mieć jakiś plan działania po powrocie.

Sterowniki maszyn cnc nie lubią emulowanych portów LPT. Jeśli port jest fabryczny nie ma problemów z czasem dostępu.
Mój laptop nie posiada również portu lpt i przesiadłem się na sterowanie przez LAN.

Port równoległy na złączu dokowania nie jest wyprowadzony wprost z płyty głównej?
Rozumiem, że port LPT na USB jest emulowany, ale byłem przekonany że złącze dokowania wyprowadza fizyczny port z płyty.

Poza tym, czy to już byłoby problemem na etapie testu? Jeszce nie doszło do żadnego sterowania. Emulowany port spowoduje błędy w stabilności sygnałów wyjściowych (nie będą deterministyczne czasowo przez co np silniki będą gubić kroki) ale czy to w jakimś stopniu przeszkadza w pracy samego programu?

Nikt nie ma pomysłu?

Ja rozumiem Twoje zamiłowanie do rozkminiania zawiłości komputera, ale czy nie szybciej byłoby sugerować się poniższą listą przed zakupem? ,
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Latency-Test
Pewnie poszukasz, pozmieniasz coś w BIOSie, albo w samym linuksie i w końcu dojdziesz, ale IMO szkoda czasu bo za 160 zł masz gotowy komp (tyle dałem za swój - chyba optiplex 960).

Lista listą, a wyniki i tak w dużej mierze zależą od konfiguracji całego systemu, a raczej jego podzespołów.
Opiszę moje boje z "latency test" i jitterem:
Przykładowo
- na jednej maszynce mam komputer na AMD Athlon XP 1800+ (karty graficznej nie pamiętam) i śmiga na mojej maszynce ładnie choć jak robiłem latency test to "base period" niby utrzymywał się w granicach 20000-30000ns, ale potrafi skoczyć po włączeniu acrobat readera do nieakceptowalnych przez instrukcję wartości. Mimo to maszynka chodzi i gubienia kroków nie zauważyłem. Tylko po włączeniu trzeba chwilę odczekać, ponieważ pojawia się komunikat o "nieoczekiwanym zachwianiu czasu rzeczywistego". Później już go nie ma. Maszynka już kilkukrotnie wykonywała programy, które pracowały ponad dwie godziny i wszystko było OK.
- mam też optiplexa bodajże 620 o ile dobrze pamiętam. Wartości "servo thread" są na poziomie 320000ns a base thread z kartą graficzną skakał strasznie. Podczas testów silniki buczały, nie chciały kręcić. Ogólnie masakra. Procek Pentium 4. Komputer poszedł w odstawkę. Ostatnio go odkopałem i wrzuciłem ostatnią wersję linuxacnc. Jitter też skakał masakrycznie, nieważne czy wyłączyłem HT czy nie. Zamówiłem więc w necie małego kompa na intelu D525 1.8GHz (o nim później) i na wbudowanej karcie było lepiej niż na optiplexie.
Wpadłem na pomysł by wywalić kartę graficzną (chyba jakaś Nvidia ale jaka nie pamiętam). Bez niej "base thread" jest jak zamurowany. Dochodzi do ok. 25000ns i dalej nie skacze mimo włączenia iluśtam glxgears. "Servo thread" jest jak poprzednio na poziomie 320000ns i to od razu po włączeniu latency test. Jak odpalę silniki i sterowniki to pobawię się na nowo optiplexem 620 i zobaczę czy wywalenie karty coś pomogło. W sumie to dziwne, ponieważ w instrukcji piszę, żeby nie używać wbudowanych kart graficznych tzn "onboard gp"
- trzeci komputer to wspomniany intel D525. Jitter zaczyna się od 7000ns ale po włączeniu kilki glxgears "base" rośnie do niecałych 50000ns (jest bardzo podobny do servo thread). Być może w tym wypadku karta graficzna by pomogła ale nie mam takiej aby pasowała do slotu PCI i do małej płyty miniitx). Jitter taki sobie ale bardziej stały niż w Athlonie. Zobaczymy w praniu jak wyjdzie podczas pracy.
- a teraz coś co mnie zaskoczyło. Puściłem sobie z USB linuxa na domowym komputerze z prockiem i3 i kartą bodajże Radeon HD4850. Komp bez portu LPT ale zawsze na PCI można dołożyć. Jiiter bez wyłączania wielowątkowości i niczego innego (nic nie zmieniałem w biosie) był taki: servo thread ok. 3000ns, a base thread na poziomi 9000ns i to przy włączonych iluśtam oknach mozilli z youtube, iluśtam glxgaers, pracy w Gimpie na pliku graficznym. Skończyłem testować po 20min i jiiter stał jak zamurowany.Obciążyłem kompa tak, że youtube już zaczęło "klatkować", a niby nowsze procki to zło w czystej postaci według obiegowych opinii.
O co więc chodzi?
Tak więc "wiem że nic nie wiem" i bez testów na danej konfiguracji i późniejszych testów z gotową elektroniką to chyba i tak niewiele jesteśmy w stanie powiedzieć na temat zestawu.

Koniec końców był taki, że z HP się nie udało. Próbowałem wiele sposobów i rozwiązań, nic nie pomagało. Problem sprzętowy, nie do rozwiązania. Przerzuciłem się na Fujitsu i tam nie ma żadnych problemów.

Testowałem mojego optiplexa 620 na nowych sterownikach i tzw "pupa w kratę". Podobnie jak u kolegi sprzęt po prostu nie nadaje się do sterowania. Stary atom D525 spokojnie sobie daje radę i silniki chodzą płynnie. Na 620-tce jęczą, brzęczą, szarpią i tracą synchroniczność mimo że wyłączyłem wszystkie opcje, które mogą szkodzić jitterowi typu HT, oszczędzanie enrgii itp. Co ciekawsze komputer na i3 z radeonem HD4850 ma lepszy jitter niż komp z i7 i GTX980Ti na pokładzie (odpalałem wersję live z pendrive).