Hög UDP men låg TCP, förslag

Vad jag vet så går det alltid slöare med TCP eftersom den hela tiden väntar på kvitto från mottagaren att datan mottagits ok.. och UDP bara skickar fortast möjligt utan att fråga efter kvitto av mottagning..

Kör testet på natten eller mycket tidigt på morgonen på bredbandsbolagets server. Då får du det bästa resultatet.

ändra tcp receive window så kan du kräma ut mer..

Jepp, samma här...:(

alla hastigheter är ju upp till och ingen garanti att du ska kunna optimera det.

Fast det verkar ändå ganska mystiskt när man maxar ner, men har knappt 1/3 hastighet upp...eller?

Jag antar att tekniken lider av en del barnsjukdomar..har ingen större erfarenhet av vdsl ...antar att man får ringa bbb och ligga på dom som en iller.

men asså.. problemet ligger ju inte i vdsl.. då hade du aldrig fått bra hastighet med udp heller.

ganska uppenbart att det är tcp som är "problemet"
problemet i det här fallet är att tcp ofta är optimerat för modem länkar eller annat skräp, receive window är då helt knasigt inställt..
vet iofs inte om widnows 2k eller liknande kanske ändrar sådant automatiskt..

hur som helst borde man kunna hitta program som ändrar det där, alternativt kan man göra det manuellt via registret.

eller ännu bättre, kör ett 'riktigt' os

har jag påstått det??
jag sa bara att en tcp implementation kan vara optimerad för modem.. det betyder inte att alla är det, eller att tcp på något sätt är det fårn början.

TCP ställer väl in windowsize själv efter hur bra eller dåligt det går att skicka. Den måste iofs utgå från någon storlek...

mm, precis som jag sa "vet iofs inte om widnows 2k eller liknande kanske ändrar sådant automatiskt.." så var jag inte riktigt säker på hur windows hanterar det hela. och det är ju precis som du säger att den utgår säkert ifrån någon hastighet..
visserligen ökar den ju window sizen sakta men säkert då den märker att det går bra att skicka, men överför man en liten fil så tar inte det så lång tid och den hinner inte öka window sizen tillräckligt för att utnyttja hela linan...

Grabbar grabbar nu tar vi det lugnt (jag antar att ni är grabbar)...

UDP går snabbare då det saknar bekräftelser. återsändningar, flödeskontroll och liknande.

Alltså kan man säga att om man skickar något med UDP så köttar det bara på utan hänseende till andra protokoll och grejer på linan (väldigt förenklat).

Man kan dock bygga in kontroller i applikationslagret el. liknande men det är en annan historia.

Kolla duplex läget. 100 full duplex ska det va med BBB.

EDIT: fick samma med 10 halv duplex men får max med 100 full.

Jag hade samma problem, men stängde just av Windows XP's QoS bandwidth reservering och kom helt plötsligt upp i 8/8 med TCP och 10/9 med UDP ^^

Tryatron: Åh...hur stänger man av den?

Kontrollpanelen - nätverksanslutningar - egenskaper för "din anslutning" -sen är det väl bara bocka q & s packet scheduler eller vad den heter, om det är det han menar.

Ah, okej...det hände inget...samma upload som tidigare...:(

Jag fick sämre TCP och bättre UDP när jag slog av den.

Även om du stänger av tjänsten QoS i Windows XP så kommer den fortfarande att roffa åt sig 20 procent. Det enda sättet att minska detta är använda ett program som heter gpedit.msc.

För att ändra detta värde gör du enligt följande:

Klicka på Start-knappen och välj sedan Kör. Skriv gpedit.msc och klicka på Ok. Klicka sedan på fliken som heter ”Dator Konfiguration” och sedan ”Administrativa Mallar”. Välj sedan ”Nätverk”.

Klicka sedan på fliken som heter ”QoS Packet Scheduler” i det vänstra fönstret. Klicka sedan på ikonen som heter ”limit reservable bandwidth” i det högra fönstret. Aktivera (enable) denna funktion och ändra värdet till 0 (noll).

Du behöver sedan starta om datorn för att ändringen ska verkställas.

Daily_rush: Tack för förklaringen!
Två följdfrågor:

1. Behövs QoS till någonting speciellt egentligen, eller är det lugnt (eller t o m bra) att ta bort det?

2. Om man behöver installera det igen, hur gör man då?

Nu har det allt blivit fel.

QOS används inte för att statiskt ta 20% bandbredd utan för att garantera bandbredden (quality of service).

Det är inget du behöver bry dig om, felet ligger inte där.

Ja eftersom tråden inte är avslutad så...

Så här fungerar det:
Datorn börjar skicka data, den ställer windowsize till ett värde som är bra mycket större än vad det bör vara. Man kommer då få en timeout vilket innebär att TCP gör en slow start och börjar om från "noll". Samtidigt som detta händer så sätter den ett värde där den ska gå in i congestion avoidance. Så nu efter att första timeouten har inträffat kommer den arbeta sig uppåt som förut fast då den kommer till det värde som congestion avoidance gav så ökar den hastigheten mycket saktare. Den kommer ju dock till slut nå den gräns där man förr fick timeout, då kommer den istället att vänta på att få ett visst antal likadana ACKar (omsändning behövs) och då det händer går den ner till värdet för congestion avoidance. Sen fortsätter det så i en "loop" tills sändningen är avslutad.

Den initiala hastigheten på en TCP-koppling skall vara MSS/RTT ( MSS = fönsterstorlek i byte, RTT=round trip time eller ping, fördröjning, lagg...). Om man har ett högt värde på MSS kommer alltså den initiala sändhastigheten vara större men de hundradelarna (eller vad det handlar om) borde inte ha så stor betydelse (om man inte har grymt bråttom då).

Med tanke på att implementationen av TCP/IP ligger i operativsystemet så tror jag inte att det finns någon speciell implementation för modem (iallafall inte i windows), men vad vet jag...

Varför UDP går fortare beror på det ovanstående. När man skickar UDP-paket så kollar man inte vilken bandbredd som finns "ledig" eller i vilken takt mottagaren kan "tillgodogöra" sig information utan man skickar och hoppas det går fint (även om andra lager i stacken kan begränsa en del tokigheter osv).

Att ändra recieve window ska således operativet klara av själv om det inte är tokigt på något sätt. Man kan ju faktiskt få lite bättre prestanda genom att ändra detta men jag vet inte om det ger så mycket. I vanliga fall så ska detta fungera och om det inte gör det så beror det nog oftast inte på att receive window är fel med tanke på att det fungerar för några miljoner andra.

TCP: http://www.ietf.org/rfc/rfc0793.txt?number=793
UDP: http://www.ietf.org/rfc/rfc0768.txt?number=768
QoS: http://www.ietf.org/rfc/rfc2990.txt?number=2990
http://support.microsoft.com/default.aspx?scid=kb;en-us;31666...

Rätta mig om jag har fel, lite "avlegad"....

Har exakt samma problem, men sitter då bakom 10Mbit och sunet.
Det konstiga var att för några månader sedan fungerade det utan några som helst problem, men sen utan någon som helst anledning så började jag få problem med att skicka filer till folk på området.
Ibland fungerar det, men som oftast ligger jag mellan 100-400kb/s.
Testade senast idag med en kompis bärbara dator i samma vägguttag för anslutningen med samma resultat som med min dator, och då fungerar hans hemma. Så jag kan trösta dig med att risken att något är fel hos dig är liten, verkar vara ett vanligt problem som inge disskuterar.