Missa inte Amazon Prime Day i Dagens fynd
Permalänk

Fan va nice. Det funkade tamejfan!

Före: ~520 kbps
Efter: ~860 kbps

Jippiehalleluja!

Fast ska man ställa in det så högt som möjligt eller vad är lagom med en telia 8/1-lina? Jag drog reglaget till 8000 och valde "Optimised settings". Blev nått med 512 000 eller nått.

Visa signatur

-Jag har visst vart ute idag.
-Vart då?
-Ne, jag öppnade fönstret förut...
www.iampear.com Hakona Matata!

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av varget
precis, när paketfelen uppkommer så tätt att tcp aldrig hinner återhämta sig skulle det kanske vart mer fördelaktigt att haft mindre fönsterstorlek.

Men congestionwindowet borde ju ha varit lika stort i båda fallen ändå. Annars kommer ju överföringshastigheten begränsas av recivewindowet.

Om man får en timeout spelar det ingen roll vad man har för window för då sätts ju congwindow till 1MSS i alla fall. Får man 3dubbla acks så halveras CongWin. Inget av dessa påverkas av recivewindow (mer än att congWin kan bli större, men större betyder ju högre överföringshastighet). Och får man en packetloss vid högre.

Men jag såg precis nått som kanske är förklaring. När congWin har kommit upp till Threshold och den slutar med den exponentiella ökningen så ökas Congwin med följande formel: CongWin=CongWin + MSS* (MSS/CongWin) . Vilket i ord betyder att den ökar 1MSS per RTT (round trip time). Detta gör att congWin ökar saktare per skickad byte. och detta innebär i sig att den ökar sakater per packetloss.

Men detta är ju fortfarande beroende av congWin och inte recivewindowet. Så antingen begränsar man farten med ett för litet recivewindow eller så har man ett "tillräckligt stort" recivewindow som nästan aldrig fylls upp. Här kanske det kan vara bättre att ha recivewindow som begränsar vid hög ping. Det verkar i alla fall inte helt otroligt att det finns en gräns där man får för mycket packetloss per RTT för att den kan återhämta sig.

Stämmer det här eller har jag fått det om bakfoten (igen)?

Citat:

Ursprungligen inskrivet av AggeMannen
Fast ska man ställa in det så högt som möjligt eller vad är lagom med en telia 8/1-lina? Jag drog reglaget till 8000 och valde "Optimised settings". Blev nått med 512 000 eller nått.

Med ett windowsize på 512 000 och en lina som klarar av 8mbit kommer du kunna tanka i maxfart så länge pingen är under 500ms. Vilket den förhoppningsvis alltid kommer att vara.

Permalänk
Medlem

LOL från 330Kb/s till 1.9Mb/s

/Homer_S1

Visa signatur

INTEL Core Ultra 7 265K @ 4.4GhZ| Gigabyte Z890 Eagle | NVidia RTX 4070 TI| 2x24Gb Kingston Fury 6000MhZ DDR5 | Kingston Fury Renegade Gen4 2Tb M.2 | EVGA Supernova 1300WATT 80+ Gold| 34" Samsung Odyssey G8 OLED (S34DG850S) | Logitech G915 Lightspeed & G903 Lightspeed on G PowerPlay mouse pad | Steelseries Nova Pro Wireless

Main TV & Sound. Samsung 75" QN85A + HW-Q910A 7.1.2ch Soundbar

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Tjofras
massa text

Stämmer det här eller har jag fått det om bakfoten (igen)?

Du hänger helt rätt med. Kan skicka lite fina grafer när jag kommer hem sen om du vill se.

Permalänk
Medlem

8mbit bostream eller vad dom heter
158kb/s före
1mb/s efter

Visa signatur

www.filipsprogram.tk - lite freeware
"Delight, herregud. Talang är bara förnamnet."

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av varget
Du hänger helt rätt med. Kan skicka lite fina grafer när jag kommer hem sen om du vill se.

Joo skulle vara kul att se, det kanske går att räkna ut hur stort man skall ha det som max innan det blir dåligt.

Permalänk
Medlem

Är detta samma windowsize som man sätter i Samba, och som man kan konfa för att öka prestandan?
Har aldrig förstått (orkat kolla upp) vad dessa två är för något, men det kankse är just TCP's windowsize?

# Most people will find that this option gives better performance.
# See the chapter 'Samba performance issues' in the Samba HOWTO Collection
# and the manual pages for details.
# You may want to add the following on a Linux system:
# SO_RCVBUF=8192 SO_SNDBUF=8192

Har för mig folk har nämnt nåt visst värde som man ej ska (får?) överskrida....vad kan det ha handlat om måntro?

Visa signatur

CCNA sedan juni 2006

Permalänk
Medlem

Även upload kan justeras!

Värt att nämna i sammanhanget, se följande gamla tråd:

http://www.sweclockers.com/forum/showthread.php?s=&postid=568...

Ytterligare en gammal tråd som behandlar samma ämne:

http://www.sweclockers.com/forum/showthread.php?s=&postid=589...

Permalänk
Medlem

Re: Även upload kan justeras!

Citat:

Ursprungligen inskrivet av berenpx
Värt att nämna i sammanhanget, se följande gamla tråd:

http://www.sweclockers.com/forum/showthread.php?s=&postid=568...

Ytterligare en gammal tråd som behandlar samma ämne:

http://www.sweclockers.com/forum/showthread.php?s=&postid=589...

Är du blandras eller?
Läcker bild iallafall.

Visa signatur

CCNA sedan juni 2006

Permalänk
Medlem

Re: Även upload kan justeras!

Citat:

Ursprungligen inskrivet av berenpx
Värt att nämna i sammanhanget, se följande gamla tråd:

http://www.sweclockers.com/forum/showthread.php?s=&postid=568...

Ytterligare en gammal tråd som behandlar samma ämne:

http://www.sweclockers.com/forum/showthread.php?s=&postid=589...

Jag får inte programmet att fungera som det ska. När jag försöker hämta info från registret händer ingenting. Har dom flyttat registernycklarna från win2k till xp?

Men intressant är det iaf, jag bara antog att windows automatiskt gjorde sin sändbuffer lika stor som mottagarens recivebuffer.

Permalänk
Medlem

Re: Re: Även upload kan justeras!

Citat:

Ursprungligen inskrivet av Tjofras
Jag får inte programmet att fungera som det ska. När jag försöker hämta info från registret händer ingenting. Har dom flyttat registernycklarna från win2k till xp?

Men intressant är det iaf, jag bara antog att windows automatiskt gjorde sin sändbuffer lika stor som mottagarens recivebuffer.

Det kan vara så att inga av parametrarna har något värde i ditt Registry.

Testa genom att ange något i DefaultSendWindow (t ex 128000 om du har 1Mbit i upload), klicka "Save to Registry" och boota om maskinen.

Sen kör du Adjuster igen och kollar om värdet finns kvar

Permalänk
Medlem

Hur är det om man sitter bakom en router. Är det routern som måste optimeras eller är det datorn?

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av dsk
Hur är det om man sitter bakom en router. Är det routern som måste optimeras eller är det datorn?

Det är datorn. routern skickar bara vidare dina paket

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av dsk
Hur är det om man sitter bakom en router. Är det routern som måste optimeras eller är det datorn?

Antagligen datorn man ställer windowsize och sånt i.
TCP är ju transparent för routern....den bara skyfflar vidare.

EDIT: En minut för sen

Visa signatur

CCNA sedan juni 2006

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Seb74
Antagligen datorn man ställer windowsize och sånt i.
TCP är ju transparent för routern....den bara skyfflar vidare.

EDIT: En minut för sen

hehe
Började dock fundera lite när man har en router som kör NAT för den går ju in och kollar i TCP headern (den byter väll tom sourceporten). Men den pillar nog inget på recivewindow fältet

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Tjofras
hehe
Började dock fundera lite när man har en router som kör NAT för den går ju in och kollar i TCP headern (den byter väll tom sourceporten). Men den pillar nog inget på recivewindow fältet

Min router kör NAT och jag får inte RWIN över 65k. Jag har startat om datorn fem gånger nu och börjar tröttna.

Om jag kör TCP Optimizer så visar den över 100k men enligt speedguide så ligger den på 65k. Först fick jag för mig att Cfosspeed ställde in RWIN så jag avinstallerade det(har 10/10 nu så förhoppningsvis behöver jag inte Cfos). Spybot S&D avinstallerade jag också. Nu ligger bara NOD32 kvar och det tänker jag inte ta bort.

Någon som har en susning om vad som kan vara fel? Är det trots allt min gateway som ställer till det?
-e- Har en Dlink DGL-4300 om det kan hjälpa.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av dsk
...
-e- Har en Dlink DGL-4300 om det kan hjälpa.

Googlade lite snabbt och hittade följande:

Citat:

Q: How to increase TCP window size (RWIN) on DGL-4100/4300 (#13040)

A: Users have noticed that the SPI setting seems to affect the maximum TCP window size. Follow these suggestions provided by joe_dude See Profile. Note: Always consider performaing a backup or creating a Restore Point before editing the Registry.

1) On the router, disable SPI under Advanced -> Firewall.

2) In Windows 2000/XP/2003, add/change the value DefaultReceiveWindow in HKEY_LOCAL_MACHINE -> SYSTEM -> CurrentControlSet -> Services -> Afd -> Parameters to greater than 65535. You may also want to increase DefaultSendWindow as well.

I recommend matching DefaultReceiveWindow to GlobalMaxTcpWindowSize in HKEY_LOCAL_MACHINE -> SYSTEM -> CurrentControlSet -> Services -> Tcpip -> Parameters.

Så prova att dissabla SPI i routern
Steg2 är vad TCPOptimizer gör åt dig, så det behöver du inte göra.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Tjofras
hehe
Började dock fundera lite när man har en router som kör NAT för den går ju in och kollar i TCP headern (den byter väll tom sourceporten). Men den pillar nog inget på recivewindow fältet

Jo det kanske inte är helt sant ändå, att den bara jobbar i lager 3.
Iallafall om man kör NAT (vilket man inte alltid gör på en router) så kollar den ju upp portnummer.
Tänkte inte på det.

Visa signatur

CCNA sedan juni 2006

Permalänk
Inaktiv

FTP: ftp://ftp.kernel.org/pub/dist/knoppix-dvd/KNOPPIX_V5.0.1DVD-2...

Före: ~50 KB/s
Efter: ~50 KB/s

:s

10/10mbit
MTU = 1500
MSS = 1460
Default TCP Receive Window (RWIN) = 513920
RWIN Scaling (RFC1323) = 3 bits (scale factor of 6)
Unscaled TCP Receive Window = 64240

Kört disable på SPI på min D-Link DGL-4100 hela tiden.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av berenpx
... ang. sendwindow...

Efter lite mer studier så verkar det ändå som om Sendwindow sätts efter en TCP handshake. Detta är oxå anledningen till varför det värdet inte sätts i TCPOptimizer. Så att sätta sendwindowet till något kommer bara att begränsa om någon annan host skulle vilja köra med ett störe reciveWindow.

ResiveWindow är det om skickas i TCP-headern, medans sendWindow bara är en lokal buffer i windows. Så min rekomendation är att inte sätta den alls, eftersom det funkar bäst när den sätts till vad den andra sidans recivewindow är.

Citat:

Ursprungligen inskrivet av JBRAA
FTP: ftp://ftp.kernel.org/pub/dist/knoppix-dvd/KNOPPIX_V5.0.1DVD-2...

Före: ~50 KB/s
Efter: ~50 KB/s

:s

10/10mbit
MTU = 1500
MSS = 1460
Default TCP Receive Window (RWIN) = 513920
RWIN Scaling (RFC1323) = 3 bits (scale factor of 6)
Unscaled TCP Receive Window = 64240

Kört disable på SPI på min D-Link DGL-4100 hela tiden.

Om du bara får 50KB/s från ftp.kernel.org så är det inte reciveWindowet som sätter gränsen. Då är det något annat. Låter väldigt mystiskt att du får så låga värden på en 10mbits lina =/

Kanske är kernel.org överbelastat eller har några andra problem för tillfället =/

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Tjofras
Googlade lite snabbt och hittade följande:

Så prova att dissabla SPI i routern
Steg2 är vad TCPOptimizer gör åt dig, så det behöver du inte göra.

Tack för det! Avmarkerade SPI och analyzer visade rätt värde.

Blev klart mycket bättre hastighet men väldigt svajigt... ligger på 300k/s i medel men det kan ju vara Bahnhof som har lite dåligt med bandbredd till USA.

Permalänk
Medlem

Förresten, ska inte TCP windowsize ändras dynamiskt...sliding windows och det där. Om paket inte ackas så tolkas det som att linan är dålig och hastigheten sänks.

Visa signatur

CCNA sedan juni 2006

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Seb74
Förresten, ska inte TCP windowsize ändras dynamiskt...sliding windows och det där. Om paket inte ackas så tolkas det som att linan är dålig och hastigheten sänks.

Jo, men det här handlar väl dels om maximal fönsterstorlek, samt vilken man ska börja med?

Visa signatur

Desktop spel m.m.: Ryzen 9800X3D || MSI X870 Tomahawk Wifi || MSI Ventus 3x 5080 || Gskill FlareX 6000 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Arbetsstation: Ryzen 7945HX || Minisforum BD790i || Asus Proart 4070 Ti Super || Kingston Fury Impact 5600 65 GB || WD SN850 2TB || Samsung 990 Pro 2TB || Fractal Ridge
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av evil penguin
Jo, men det här handlar väl dels om maximal fönsterstorlek, samt vilken man ska börja med?

Ah ok, tänkte inte på att man behöver ha en start samt maximal storlek.

Visa signatur

CCNA sedan juni 2006

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Seb74
Ah ok, tänkte inte på att man behöver ha en start samt maximal storlek.

Det du tänker på är congestionwindowet, detta kommer att börja på 1 och sedan växa. Recivewindowet är det window som bestämmer flowcontrollen och det bestämmer även den maximala storleken på congestionwindowet.

Permalänk
Medlem

Tips på lite intressant läsning om TCP/IP-stacken i Windows XP samt vilka förbättringar som gjorts i Microsofts "Next Generation TCP/IP Stack" som finns i Windows Vista:

Microsoft TechNet: Performance Enhancements in the Next Generation TCP/IP Stack

Permalänk
Medlem

Tackar. Det jag märkte va att själva surfande gick mycket snabbare till än innan. Alltså sidorna laddas ner snabbare, och det är ingen inbillning utan det märks.
_Sen när jag testade FTP så gjorde jag innan 250 efter optimeringen så gick det upp till 518. Så visst är det skillnad. Det enda jag gjorde va att klicka i Optimal settings och dra upp spaken till 20000. Sparade startade om och går som smör.
Är det nåt mer jag skall tänka på eller ändra eller kontrollera.
Tack.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av JohanS
Tips på lite intressant läsning om TCP/IP-stacken i Windows XP samt vilka förbättringar som gjorts i Microsofts "Next Generation TCP/IP Stack" som finns i Windows Vista:

Microsoft TechNet: Performance Enhancements in the Next Generation TCP/IP Stack

Ser välldigt lovande ut

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av JohanS
Tips på lite intressant läsning om TCP/IP-stacken i Windows XP samt vilka förbättringar som gjorts i Microsofts "Next Generation TCP/IP Stack" som finns i Windows Vista:

Microsoft TechNet: Performance Enhancements in the Next Generation TCP/IP Stack

Är det sånt BSD-världen haft länge eller?
Tänker på att Windows en gång i tiden lånade typ hela TCP-stacken från nån av BSD-varianterna....tänkte att det kanske var så fortfarande att BSD ligger före i den utvecklingen?

Visa signatur

CCNA sedan juni 2006

Permalänk
Medlem

Provade även på min bärbara och det va skillnad. Den funkar verkligen bra.