io.dll (geekhideout.com) en de snelheid van data overdracht

[Lorn]

Het project
Ik ben bezig met het maken van een stukje software waarmee onder Windows een pager kan worden uitgelezen. De pager is via een soort cradle verbonden met de PC via de LPT-poort.

De omgeving
Ik ontwikkel de software onder Windows XP SP2 met Visual Basic 6SP5. Voor interactie met de parallelle poort gebruik ik de io.dll van Geek Hideout. Dit is ook de reden waarom ik geen [VB6] heb gebruikt in de topic titel, ik denk dat mijn probleem taal onafhankelijk is. Verder heb ik nog twee test machines, eentje met Windows 2000 SP2 en een kale Windows XP.

Het probleem
Het probleem dat ik heb is de snelheid waarmee de pager wordt uitgelezen. De pager heeft 128 geheugen adressen en per adres kost het 1.3 seconden om het uit te lezen. Dit is nogal traag. Op sommige momenten kost het echter maar 0.18 seconden om een adres uit te lezen, dit is een snelheid die je eerder zou verwachten. Het uitlezen van de pager varieert nu tussen de 2m54s en 24s.

De oorzaak?
Na veel proberen heb ik ontdekt onder welke omstandigheden de pager maar 0.18 seconden nodig heeft om een adres uit te lezen. Dit is echter zo merkwaardig dat ik helemaal niet meer weet waar ik moet zoeken. De pager wordt snel uitgelezen als ik Internet Explorer heb open staan. Niet elke website werkt, Tweakers.net bijvoorbeeld heeft geen enkele invloed. Echter bij msn.nl en nu.nl gaat de pager als een speer! Na nog wat meer 'onderzoek' blijkt dat het open hebben staan van MS Mediaplayer ook versnellend werkt

Oplossing?
Is er een Tweaker die dit herkent? Ik snap helemaal niet hoe Internet Explorer of Mediaplayer invloed kunnen hebben op de snelheid waarmee data over de LPT-poort komt. Ook zoeken met Google heeft me geen resultaat opgeleverd. Alle hulp is welkom!

[Fairy]

Misschien heb je er wat aan maar bij ons op de zaak hebben we handscanners (barcodescanners) en daar moet 1 keer in de week een barcodebestand op worden gezet met een dos progje onder win2k server.

Als je dat progje start gaat ntvdm.exe 99% cpu trekken. Dit proces 'emuleert' enen dos klok meen ik, maar hierdoor gaat het inladen supertraag. Als je dan via de task manager het proces een low priority meegeeft dan gaat het ook ineens als een speer (die barcodescanners van ons zijn serieel).

Kijk anders ook eens of jij in je task manager een proces hebt wat alle performance opslokt, of draai een realtime dos applicatie samen met de overdracht en kijk wat er gebeurt.

[farlane]

In welke instructies gaat die tijd zitten dan? In de IO zelf, of in een ander deel van je app? Ik kan me namelijk niet voorstellen dat IE invloed kan hebben op de snelheid v/d paralele poort.

[Lorn]

Fairy schreef op donderdag 02 december 2004 @ 15:34:
Kijk anders ook eens of jij in je task manager een proces hebt wat alle performance opslokt, of draai een realtime dos applicatie samen met de overdracht en kijk wat er gebeurt.

De CPU wordt niet 100% belast, als het 5% is het al veel. Ik heb verder verschillende process prioriteiten geprobeerd (van laag tot realtime) maar geen van alle had invloed op de snelheid van het uitlezen van de pager.

farlane schreef op donderdag 02 december 2004 @ 15:57:
In welke instructies gaat die tijd zitten dan? In de IO zelf, of in een ander deel van je app? Ik kan me namelijk niet voorstellen dat IE invloed kan hebben op de snelheid v/d paralele poort.

De tijd gaat echt zitten in de PortOut /PortIn aanroepen, het zit echt in de IO zelf. Ik ben het helemaal met je eens dat het heel vreemd is dat IE en Mediaplayer invloed hebben op de snelheid maar zo is het momenteel toch echt.

Ik heb nog heel even gedacht dat IE misschien nog iets initialiseerd op een bepaalde manier. Het is dan alleen weer niet logisch dat het uitmaakt welke pagina je in je browser hebt staan.

[RobIII]

Lorn schreef op donderdag 02 december 2004 @ 17:20:
Het is dan alleen weer niet logisch dat het uitmaakt welke pagina je in je browser hebt staan.

Is het ook betrouwbaar te reproduceren? (dus ook na reboots etc) Of is het toeval? Want dit is inderdaad sterk werk

[ Voor 5% gewijzigd door RobIII op 02-12-2004 17:50 ]

[Fairy]

Al gespeeld met andere port modes? EPP, SPP, BI-Dir ?

[Lone Gunman]

Het verschijnsel klinkt me erg bekend, en ik denk dat het hier van toepassing is. Het komt er op neer dat in bepaalde omstandigheden de Sleep() functie van windows nauwkeuriger werkt zodra er bijvoorbeeld een xvid afgespeeld wordt, of als er een site met flash openstaat. Als ik het goed herinnerer wordt de nauwkeurigheid van een Sleep() maar gegarandeerd tot 11 msec op win2k/xp.
Dus een Sleep(2) kan 11 msec duren ipv 2. Maar... zodra je dus bv een xvid afspeelt, wordt de nauwkeurigheid hoger, waardoor de Sleep(2) bijvoorbeeld 3 msec duurt.

K heb het voor de zekerheid even getest:

C:

#include <windows.h>
#include <cstdio>

int main()
{
    DWORD beginTime = GetTickCount();

    for(int i = 0; i < 1000; ++i)
        Sleep(2);

    printf("Time passed in msec: %d\n", GetTickCount()-beginTime);
}

En daarna getest op een winxp sp2 computer:

Als er geen programma's draaien op de pc:
D:\>sleep
Time passed in msec: 15625

Als er een xvid speelt:
D:\>sleep
Time passed in msec: 2938

Het lijkt er dus op dat de io.dll gebruik maakt van Sleep()'s voor bepaalde timing issues, of je gebruikt zelf Sleep()'s voor de timing in je programma. In het laatste geval moet je een andere oplossing zoeken, en in het eerste een betere dll...

[edit] nog wat extra testjes:

Getest op een win2k sp4 pc:

geen programma's:
D:\>sleep
Time passed in msec: 15703

firefox gestart met www.nu.nl
D:\>sleep
Time passed in msec: 2953

firefox afgesloten:
D:\>sleep
Time passed in msec: 15656

mp3 gestart met foobar2000:
D:\>sleep
Time passed in msec: 15734

eigen programma gestart welke gebruikt maakt van een multimedia timer (multimedia timer met een resolutie van 5 msec):
D:\>sleep
Time passed in msec: 3953

Het lijkt erop dat de nauwkeurigheid van Sleep() op een of andere manier samenhangt met het gebruik van multimedia timers (met als aanname dat bepaalde mediaplayers en bv flash hier gebruik van maken).

[ Voor 27% gewijzigd door Lone Gunman op 02-12-2004 18:37 ]

[Lorn]

RobIII schreef op donderdag 02 december 2004 @ 17:50:
[...]

Is het ook betrouwbaar te reproduceren? (dus ook na reboots etc) Of is het toeval? Want dit is inderdaad sterk werk

Ja, dit is betrouwbaar te reproduceren Ik kan zo veel rebooten als ik wil, cradle afkoppelen en weer aankoppelen, verschillende pagers gebruiken. Maakt niet uit wat je doet, het blijft werken zoals ik heb beschreven.

Fairy schreef op donderdag 02 december 2004 @ 17:59:
Al gespeeld met andere port modes? EPP, SPP, BI-Dir ?

Nee, dat heb ik niet gedaan. Ik heb wel alle instelligen van de LPT-poort onder apartbeheer geprobeerd van wel /geen interrupts gebruiken. Dat had geen enkel effect.

Lone Gunman schreef op donderdag 02 december 2004 @ 18:02:
Het verschijnsel klinkt me erg bekend, en ik denk dat het hier van toepassing is. Het komt er op neer dat in bepaalde omstandigheden de Sleep() functie van windows nauwkeuriger werkt zodra er bijvoorbeeld een xvid afgespeeld wordt, of als er een site met flash openstaat. Als ik het goed herinnerer wordt de nauwkeurigheid van een Sleep() maar gegarandeerd tot 11 msec op win2k/xp.
[...]
Het lijkt erop dat de nauwkeurigheid van Sleep() op een of andere manier samenhangt met het gebruik van multimedia timers (met als aanname dat bepaalde mediaplayers en bv flash hier gebruik van maken).

Dit lijkt me een hele goede mogelijkheid! Ik gebruik inderdaad hier en daar een keertje Sleep() in mijn code. De code van io.dll is niet vrij verkrijgbaar, kost USD 1000,-. Weet dus niet of daar Sleep() in wordt gebruikt.

Maar dan zal ik dus eens gaan testen met de multimedia timer. Weet iemand een goede DLL /OCX die ik kan gebruiken voor deze timer? Kan ook wel zelf de API-calls groeperen in een DLL maar het zou handiger zijn als ik al bestaande code hiervoor kan gebruiken. Heb morgen de ochtend vrij, zal het vrijdagmiddag zeker uit proberen!

[DRAFTER86]

Ik zelf gebruik de genoemde dll onder C# .Net, en ik moet zeggen dat het snelheids verschil met VB6 erg groot is. Ik kan me voorstellen dat je hier niet op zit te wachten, maar overstappen naar .NET is misschien de moeite waard?

[Lorn]

DRAFTER86 schreef op donderdag 02 december 2004 @ 20:20:
Ik zelf gebruik de genoemde dll onder C# .Net, en ik moet zeggen dat het snelheids verschil met VB6 erg groot is. Ik kan me voorstellen dat je hier niet op zit te wachten, maar overstappen naar .NET is misschien de moeite waard?

Overstappen naar .NET zou een optie zijn ware het niet dat ik vast zit aan een deadline en een budget. Zou geen schatting durven te maken over de tijd die ik kwijt ben naar het omzetten naar .NET. Bovendien is een overstap naar .NET ook niet echt nodig, de pager kan immers in 24 seconden worden uitgelezen wat meer dan snel genoeg is.

[farlane]

Lorn schreef op donderdag 02 december 2004 @ 19:54:
Dit lijkt me een hele goede mogelijkheid! Ik gebruik inderdaad hier en daar een keertje Sleep() in mijn code. De code van io.dll is niet vrij verkrijgbaar, kost USD 1000,-. Weet dus niet of daar Sleep() in wordt gebruikt.

Whaaaaat? $1000 !!!!!? *kuch* rippoff *kuch*

Wat in de f*ck kun je er nog meer mee dan ? Kan ie ook koffie zetten ?

[Lorn]

farlane schreef op donderdag 02 december 2004 @ 21:33:
[...]


Whaaaaat? $1000 !!!!!? *kuch* rippoff *kuch*

Wat in de f*ck kun je er nog meer mee dan ? Kan ie ook koffie zetten ?

Ja, dat was ook mijn reactie. Je kunt zelfs, mocht je geld genoeg hebben, bepaalde custom modifications laten opnemen in io.dll tegen betaling.

Was trouwens vergeten dat ik naast io.dll ook heb getest met portio.dll van SST. Deze dll toont precies hetzelfde gedrag als io.dll. Begin echt steeds meer te geloven dat het inderdaad de Sleep() commando's zijn die roet in het eten gooien. Kan niet wachten om het morgen te kunnen testen!

[DRAFTER86]

farlane schreef op donderdag 02 december 2004 @ 21:33:
[...]


Whaaaaat? $1000 !!!!!? *kuch* rippoff *kuch*

Wat in de f*ck kun je er nog meer mee dan ? Kan ie ook koffie zetten ?

Heuh ja, toevallig stuur ik momenteel via deze dll een schuifregister en een paar relais aan waar onder andere een koffiezetapparaat aan hangt

[ Voor 3% gewijzigd door DRAFTER86 op 02-12-2004 22:45 ]

[Lorn]

Ik wou even iedereen bedanken die heeft mee gedacht! Het probleem is opgelost, het was inderdaad Sleep() die de boosdoener was. Had een Wait functie geschreven die gebruik maakt van de Multimedia timer, daarna waren alle problemen over. Pager wordt nu keurig in 24 seconden uitgelezen ongeacht welke applicaties open staan. Helemaal top dus!

[farlane]

Lorn schreef op zondag 05 december 2004 @ 16:46:
Ik wou even iedereen bedanken die heeft mee gedacht! Het probleem is opgelost, het was inderdaad Sleep() die de boosdoener was. Had een Wait functie geschreven die gebruik maakt van de Multimedia timer, daarna waren alle problemen over. Pager wordt nu keurig in 24 seconden uitgelezen ongeacht welke applicaties open staan. Helemaal top dus!

Denk je er aan dat de multimediatimer event functie in een andere draad draait dan die waaruit ie gestart is?

[Lorn]

farlane schreef op maandag 06 december 2004 @ 10:49:
[...]


Denk je er aan dat de multimediatimer event functie in een andere draad draait dan die waaruit ie gestart is?

Da's een goede... zou ik dus helemaal niet aan gedacht hebben. Wat voor problemen kan ik daar door nog tegen komen?

[farlane]

Lorn schreef op maandag 06 december 2004 @ 11:38:
[...]

Da's een goede... zou ik dus helemaal niet aan gedacht hebben. Wat voor problemen kan ik daar door nog tegen komen?

In het meest vervelende geval niets, als je geluk hebt crashed de applicatie.

Ff zonder gein, VB is niet *kuch* zonder meer *kuch* geschikt om multithreaded functies te gebruiken.
Ik heb het opgelost door de mm timer in een COM dll te vrotten ( mbv VC++ ) en de events te marshallen naar de goede thread mbv een message window. Anywayz, op die manier gaat er natuurlijk wel een gedeelte van de nauwkeurigheid van de mm timer down the drain, maar je app crashed tenminste niet. ( En toch nog een behoorlijke nauwkeurigheid )

Vraag is natuurlijk ook of je wel die multimedia timers nodig hebt. Voldoet een simpele windows timer niet?

[ Voor 8% gewijzigd door farlane op 06-12-2004 13:39 ]