[C++] Vage socket situatie...

[Verwijderd]

Ik zit momenteel met een vage situatie rond windows sockets.

Er is een applicatie ontwikkeld in Visual Studio C++ 6.0. Deze applicatie bestaat uit een server en een client. Tijdens de testfase stuurt de client 1024 bytes naar de server. De server stuurt vervolgens weer 1024 bytes terug. Dit gaat zo eeuwig door om te kijken wat de maximale throughput is op deze manier.

Lokaal trok deze applicatie 5-6 MB/s, en rond de 5 MB/s over een 100Mbit netwerk. Daar dit zowel lezen als versturen is zat de applicatie over een 100Mbit netwerk rond de 11MB/s. Dit komt aardig in de buurt van de werkelijkheid (99% netwerkverbruik). Tot dusver geen enkel vuiltje aan de lucht .

Het probleem kwam met Visual Studio 2005. De performance van dezelfde applicatie is nu gezakt naar 3 MB/s (= dus 6MB/s full-duplex) over hetzelfde 100Mbit netwerk. Aan de code is niets veranderd. Wanneer ik de binary van Visual Studio 6.0 uitvoer dan zit ik met dezelfde performance loss.

Als idee kwam er op om de applicatie te draaien op een Windows 2003 Enterprise server. Dit is echter niet mogelijk i.v.m. foutmeldingen rondom .NET. Echter staat in Visual studio Common Language Support op No Common Language Support. Vanwaar deze melding??? .

Kan het zijn dat de winsock implementatie van VS2005 ten op zichte van 6.0 veel trager is? Of is er ergens een verborgen flag waarmee de performance weer op te vijzelen is?

Reeds geprobeerd:
- Het aanpassen van de send/receive window naar 512k
- Met en zonder Nagle (TCP_NO_DELAY)
- Non-blocking en blocking sockets

En op dit moment zit ik zonder ideeën dus hoop ik dat iemand hier met een biljante ingeving gaat komen die mij weer op het juiste pad brengt

B.v.d

[martijn_brinkers]

Deze zin snap ik niet

Wanneer ik de binary van Visual Studio 6.0 uitvoer dan zit ik met dezelfde performance loss.

Dus als ik het goed begrijp heb je het probleem ook als je VS 6 gebruikt? Draaide je eerst op een andere machine?

[JeRa]

Verwijderd schreef op dinsdag 19 september 2006 @ 10:11:
Lokaal trok deze applicatie 5-6 MB/s, en rond de 5 MB/s over een 100Mbit netwerk. Daar dit zowel lezen als versturen is zat de applicatie over een 100Mbit netwerk rond de 11MB/s. Dit komt aardig in de buurt van de werkelijkheid (99% netwerkverbruik). Tot dusver geen enkel vuiltje aan de lucht .

Met een full-duplex 100 Mbit/s-netwerk heb je toch een bandbreedte van 200 Mbit/s? Dus 100 Mbit/s up én down?

[planB]

Zo maar een vraagje: gebruik je MFC classes, en zo ja, zijn die statisch of dynamisch(=DLL) ingelinkt (in je VC6 project).
Daar zou namelijk een verschil kunnen zitten.
Als je ze via de shared DLL gebruikt, gebruikt je VC6 binary nu waarschijnlijk de DLL van VS 2005.

[Verwijderd]

TijnFLiP schreef op dinsdag 19 september 2006 @ 10:26:
Deze zin snap ik niet

[...]

Dus als ik het goed begrijp heb je het probleem ook als je VS 6 gebruikt? Draaide je eerst op een andere machine?

Wanneer ik de executable uitvoer welke door Visual Studio 6.0 is gecompileerd dan heb ik ook ineens een slechte performance. De performance is spontaan slechter geworden op het moment dat Visual Studio geinstalleerd is. Met de bovenstaande zin deed ik een poging dit duidelijk te maken .

Verder werk ik nog steeds op dezelfde machine. Wat ik zo idioot vind is dat de performance ingezakt is na de installatie van VS2005. Dan zou je toch vermoeden dat VS2005 iets doet met Windows waar ik eigenlijk niet vrolijk van wordt .

JeRa schreef op dinsdag 19 september 2006 @ 10:30:
[...]

Met een full-duplex 100 Mbit/s-netwerk heb je toch een bandbreedte van 200 Mbit/s? Dus 100 Mbit/s up én down?

, het gaat hier dus om een conventionele 100Mbit verbinding, mijn fout . Komt door het vroege tijdstip .

planB schreef op dinsdag 19 september 2006 @ 10:31:
Zo maar een vraagje: gebruik je MFC classes, en zo ja, zijn die statisch of dynamisch(=DLL) ingelinkt (in je VC6 project).
Daar zou namelijk een verschil kunnen zitten.
Als je ze via de shared DLL gebruikt, gebruikt je VC6 binary nu waarschijnlijk de DLL van VS 2005.

Er wordt geen gebruik gemaakt van MFC. Het gaat hier om een console application.

[ Voor 8% gewijzigd door Verwijderd op 19-09-2006 10:45 ]

[martijn_brinkers]

Met de informatie die je geeft valt er toch weinig over te zeggen. Zeker omdat je het niet kan reproduceren. Misschien had je eerst wel QOS uitgezet en heeft VS2005 het weer aangezet?

http://www.pcnx.com/tips/browse/54/

Of had je je netwerk parameters getweaked en heeft de installatie van VS2005 dat weer ongedaan gemaakt.

[RobIII]

TijnFLiP schreef op dinsdag 19 september 2006 @ 12:58:
Met de informatie die je geeft valt er toch weinig over te zeggen. Zeker omdat je het niet kan reproduceren. Misschien had je eerst wel QOS uitgezet en heeft VS2005 het weer aangezet?

http://www.pcnx.com/tips/browse/54/

Of had je je netwerk parameters getweaked en heeft de installatie van VS2005 dat weer ongedaan gemaakt.

Dat QoS bandbreedte in beslag neemt zonder dat je het gebruikt is een dikke vette mythe:

quote: http://support.microsoft....spx?scid=kb;en-us;Q316666

Clarification about the use of QoS in end computers that are running Windows XP
As in Windows 2000, programs can take advantage of QoS through the QoS APIs in Windows XP. One hundred percent of the network bandwidth is available to be shared by all programs unless a program specifically requests priority bandwidth. This "reserved" bandwidth is still available to other programs unless the requesting program is sending data. By default, programs can reserve up to an aggregate bandwidth of 20 percent of the underlying link speed on each interface on an end computer. If the program that reserved the bandwidth is not sending sufficient data to use it, the unused part of the reserved bandwidth is available for other data flows on the same host.

For more information about the QoS Packet Scheduler, see Windows XP Help. Additional information about Windows 2000 QoS is available in the Windows 2000 technical library.

Correction of some incorrect claims about Windows XP QoS support
There have been claims in various published technical articles and newsgroup postings that Windows XP always reserves 20 percent of the available bandwidth for QoS. These claims are incorrect. The information in the "Clarification about QoS in end computers that are Running Windows XP" section correctly describes the behavior of Windows XP systems.

Zie ook: http://mywebpages.comcast.net/SupportCD/XPMyths.html

[ Voor 13% gewijzigd door RobIII op 19-09-2006 13:10 ]

[H!GHGuY]

Het lijkt alsof je telkens wacht op die 1024 byte die de ander zendt.

zo krijg je nooit de volle bandbreedte en kan een hoge ping de performantie compleet de grond in duwen.

Beter zou zijn om je app multi-threaded te maken waarbij 1 thread constant leest en de andere constant schrijft.

[Soultaker]

Ik kan me niet herinneren ooit meer dan 70% van de bandbreedte gehaald te hebben op een lokaal netwerk, dus ik denk dat je oorspronkelijke test al stuk was. Verder heb ik niet echt een idee wat er stuk gaat, maar als je met TCP nog wel dezelfde throughput haalt, is er weinig mis, denk ik. Dan moet je het probleem eerder in rare timing of rare fragmentatie zoeken.

[MSalters]

Een VC6 app heeft 0,0 te maken met .NET en CLR. Ik vermoed dus dat er iets mis is wat niet uit de TS blijkt.

[Verwijderd]

Okee, het tekort aan snelheid is nu opgelost (door het vergroten van de TCP window en het vergroten van de buffer welke verstuurd wordt). We zitten nu met een ander luxe probleem . Zie dit topic en laat even weten wat jullie eerlijke mening hierover is: [TCP] Te hoge snelheid