Grabit niet meer stabiel na snelheidsverhoging

[mike30]

Goedendag,

Ik heb sinds vandaag 23/6 een snelheidsverhoging van 30mbit naar 90mbit. Dit ivm abbonnement wijziging omdat onderling bellen bij Ziggo niet meer gratis is en ik dus dan liever sneller internet had. Ik gekeken op speedtest.net en wijziging was doorgevoerd. Dus ik ook m'n threads in grabit verhoogd. Bij opstarten loopt hij de goede snelheid maar valt daarna terug naar een minimum van 4000 kbps en haalt bij lange na niet de beloofde 11000 kbps.
Ik heb m'n modem nog niet gereset maar als m'n snelheid het doet en dit ook zichtbaar is lijkt me dit niet nodig toch?
Ga m sowieso even resetten morgenochtend en m'n router ook en heb sunnyusenet al een mail gestuurd. Heb hier al eerder last van gehad maar geen idee wat ik toen gewijzigd hebt.
Heb een cisco modem en zit plus minus 8 meter van de wijkcentrale en heb sinds vorig jaar een nieuwe kabel plus modem.

[TECHcrime]

Wat voor usenet abbo heb je? Als deze tot 40mbit is, dan is het logisch dat je niet harder gaat? Welke usenetp provider en welk abbo?

[mike30]

Heb sunnyusenet. Eerst 30mbit maar na m'n verhoging m'n abbo verhoogd naar 90 mbit. Zover was ik nog wel

[RedHat]

Gebruik je voldoende threads?

[basdej]

Kan je computer het wel aan?

[mike30]

Ja gebruik voldoende threads en m'n pc is pas nieuw. I5 4670k, 8 gig ram. 4 x 1 tb samsung spinpoint f3 + 1 x samsung 840 ssd. Snap alleen niet wat dat te maken zou hebben met een verbinding die niet stabiel is?

Als ik een download start dan loopt hij gewoon niet stabiel. Hiervoor had ik gewoon een rechte lijn op 3300 kbps ongeveer wat zo bleef tot de download klaar was. Nu is het 90 mbit en schommelt hij constant en valt hij af en toe ook weg. Het is geen rechte lijn meer.



Sorry het plaatje wil het niet doen blijkbaar

[ Voor 49% gewijzigd door mike30 op 23-06-2014 18:06 ]

[dion_b]

Haal geen dingen door elkaar. Zoals jij het beschrijft is je verbinding prima stabiel (geen uitval!) maar ervaar je hooguit instabiele snelheid in welgeteld een toepassing.

Begin eens met een andere toepassing te testen, bijv Ziggo's eigen speedtest en vervolgens die van andere provider, bijv concurrent KPN. Als dat snel is ligt het aan NNTP (en dus nadrukkelijk niet je ISP), is dat traag, negeer dan NNTP (want teveel variabelen) en troubleshoot verder met simpelere (speed)tests. Als je bij kabelinternet begint over afstand tot centrale weet je iig niet waar je het over hebt, dus zou het je sieren om niet gelijk hoog van toren te blazen over je ISP

[mike30]

Heb speedtest.net ziggo speedtest gedaan en allemaal komen ze rond de 90 mbit uit dus dat werkt. Alleen in grabit gaat het niet goed. Aangezien ik grabit opnieuw heb ingesteld op aanraden van sunnyusenet met hun configurator en dit dus goed zit zou ik zo niet meer weten waar het dan aan ligt? Enige wat ik heb gedaan is m'n abbo aangepast en daarop ook m'n abbo bij sunny aangepast.
Vanmorgen m'n router + modem gereset. Modem is ook pas nieuw. En waar ben ik hoog van de toren aan het blazen over m'n isp ?

[zjorsie]

Kijk je instellingen eens na (vooral je aantal threads).

een plaatje is toch wel handig als we willen zien wat het probleem nou echt is.

probeer eens een speedtest die wat langer duurt (1000mb.bin van een of andere server downloaden). zie je daar ook die verschillen?

[mike30]

Ik zal het plaatje nog eens proberen.



Hoop dat het zo werkt.

De grafiek wordt nog instabieler naarmate de download vordert zeg maar. Heb aantal threads al teruggeschroefd van 15 naar bv 14,13 of 12 maar dat maakt ook geen verschil. Zat eerst te denken dat m'n HDD het niet bij kan houden of zo maar dan zouden er gewoon heel veel bestanden staan die nog decoded moesten worden.

[ Voor 50% gewijzigd door mike30 op 23-06-2014 18:47 ]

[Moning2]

Laat ook eens de actieve tijd e.d. zien van je schijf waarop de tijdelijke bestanden worden gezet, en de schijf waarop de complete bestanden worden gezet. Je hebt vast een fantastische pc, maar 10MB/s wegschrijven in vele verschillende kleine bestanden kan van invloed zijn.
Tevens wordt mogelijk maar 1 cpu kern gebruikt. Laat hier ook eens het gebruik van zien.

Minder threads met dezelfde snelheid laat de nog bestaande threads harder lopen. Dit hoeft dus niet per sé verschil te maken bij jouw probleem.

Ben je trouwens bekend met het fenomeen screenshot met print screen? Google dat anders eerst even.

[ Voor 13% gewijzigd door Moning2 op 23-06-2014 18:52 ]

[mike30]

Weet niet of jullie hier wat mee kunnen ?

[MicGlou]

Moning2 schreef op maandag 23 juni 2014 @ 18:49:
Minder threads met dezelfde snelheid laat de nog bestaande threads harder lopen. Dit hoeft dus niet per sé verschil te maken bij jouw probleem.

Mbt tot een schommelende snelheid wel want meer threads zorgen in principe voor een stabieler verbinding omdat je bandbreedte wordt verdeeld. Wat je zegt mbt tot de schijven is idd een belangrijk stukje... ik had de temp map al naar een andere schijf verplaatst bij 60mbit omdat het duidelijk prestatieproblemen opleverde bij downloaden+parren en rarren op dezelfde schijf. In Newsleecher kreeg ik dan altijd de melding 'waiting for queue...' en dat betekende simpelweg dat het downloaden begon te haperen omdat de hdd het niet meer bij kon benen.

Maar de TS-er zal even bij de basis moeten beginnen en een andere netwerkkabel proberen, een andere pc/laptop op de verbinding testen etc. Dat is de snelste methode om vast te kunnen stellen of de oorzaak in de pc moet worden gezocht of vanaf de netwerkaansluiting.

[ Voor 23% gewijzigd door MicGlou op 23-06-2014 19:10 ]

[mike30]

Netwerkkabel kan ik wel proberen maar andere pc of laptop heb ik niet 1 2 3 tot m'n beschikking. Is gewoon raar omdat hiervoor met m'n 30mbit alles prima ging en nu niet. Heb hiervoor ook al 120mbit gehad en ging toen ook goed.

Ik zie trouwens op dat plaatje van me wel dat m'n ethernet signaal niet stabiel is. Hiervoor een keer eerder dit gehad en dat lag toen aan een defect UBEE modem. Heb nu een cisco modem. Zal morgen ziggo wel even bellen en kijken of hun wat kunnen zien eventueel.

EDIT: heb even m'n router ertussen uit en het lijkt nu stabieler. Niet zo stabiel als dat het zou moeten zijn maar wel beter dus m'n router zou een storende factor kunnen zijn. Alhoewel dit nooit zo geweest is maar dingen kunnen natuurlijk altijd stuk gaan. Heb ziggo gebeld en het modem functioneert volgens ziggo prima en ze zien geen dipjes in de verbinding. Dus lijkt te vanaf m'n modem of router fout te gaan. Ik ga morgen nog eens m'n kabel nalopen. Heb toen ik hier ben komen wonen een cat5 kabel gesplitst zodat ik 2 draden kon gebruiken voor telefonie. Dit heeft nooit een probleem opgeleverd maar ga morgen de kabel wel herstellen.

[ Voor 77% gewijzigd door mike30 op 23-06-2014 20:36 ]

[Moning2]

Taakbeheer geeft de throughput van Ethernet weer. Als GrabIt schommelende snelheid heeft, zal die ook schommelen.

Wat ik wel zie is dat Schijf 1 volop draait om een download te repareren en uit te pakken. Daarbij zie ik ook dat daarvoor de nodige dipjes in snelheid te zien zijn.

Het ziet er naar uit dat je met een hoge snelheid download naar een schijf die ook nog eens op volle snelheid moet uitpakken. Aangezien je schijf hier overduidelijk de bottleneck is (je CPU kan het decoden/uitpakken/repareren/etc. makkelijk aan), is dit aan te wijzen als de oorzaak van je probleem. Dan heb je enkele keuzes:
- Uitpakken naar een andere schijf (laagste winst in snelheid)
- Instellen dat hij pas repareert en uitpakt als alle downloads klaar zijn
- ..of downloads pauzeren wanneer hij repareert en uitpakt (deze twee zullen op lange termijn sneller downloaden inhouden, het kan dan namelijk beter profiteren van sequentiële snelheden)
- Je schijven in RAID0 zetten

[mike30]

Ik ben er ook net achter....ongeveer hetzelfde. Ik heb nu een andere schijf geselecteerd en nu loopt hij wel zo goed als stabiel. Deze schijf is ook minder vol en dit lijkt ook van invloed te zijn. Kan natuurlijk ook zijn dat m'n D schijf niet fris meer is aangezien dit de schijf is die het meeste gebruikt wordt. Maar vooralsnog lijkt dit m'n probleem op te lossen

[dion_b]

Als je met NNTP (ongeacht client) hogere snelheden wilt halen moet je sterk letten op I/O. Je hebt in beginsel drie verschillende activiteiten die schijven bezet houden:

- download zelf
- scratch voor parren
- wegschrijven uitgepakt resultaat

Het probleem is niet totale bandbreedte (althans niet bij slechts 90Mbps), het is drie verschillende soorten access tegelijk. Een HDD is erg goed in linear reads/writes, maar beroerd in random reads en writes ivm seek times (draaien schijf tot data onder leeskop staat). Deze drie tegelijkertijd op zelfde schijf doen is dus funest voor performance. Komt bij dat de scratch vrijwel per definitie random is.

Idealiter wil je dus originele downloads op schijf 1 doen, scratch op SSD en uitgepakte zooi op schijf 2. Zo kun je echt hoge snelheden halen, ik heb alleen door SSD in te zetten bijv m'n 200Mbps vol kunnen trekken.

Maar blijft de vraag waar het in vredesnaam nodig voor is aangezien je nooit zo snel kunt kijken als je kunt downloaden bij dit soort bandbreedtes. Geld uitgeven voor snellere NNTP toegang had je dus net zo gied kunnen verbranden...

[basdej]

Ik zie dat je grabit aan het repairen en extracten is, als je dat uit zet gaat het veel sneller

[mike30]

@ Dion_B Je bedoelt met scratch je cache neem ik aan?

[dion_b]

Iedere app heeft er een andere naam voor, iig de opslag waar tijdelijk gedumpt wordt tijdens rarren/parren.