Lancache - Hardware raid vs NVMe

[JacobsT]

Beste Tweakers,

Ik host regelmatig bij mij thuis een LAN party voor 10 mensen. Deze maal gaan we naar de maximale capaciteit van 14 mensen.

(picture for attention - and because it's fun )


Nu met elke LAN makkelijk meer dan 2 Terra aan downloads te hebben, leek het me toch is tijd voor een deftige lancache op te zetten. Blijkbaar slagen mensen er maar niet in om op voorhand toch wat basic games te downloaden en ik heb een 1 gbit lijn naar het internet en als je met 7 man een triple A titel van 80Gb wil downloaden ben je natuurlijk even zoet.

Ze delen met 3, 4 mensen een kleine ubiquiti switch steeds met een enkele Gbit uplink.
De lancache zou ik verbinden aan de 'backbone' in de gameroom via 10gbit SFP.
Theoretisch zouden we dus ergens een cap van ergens 6gbit halen in optimale omstandigheden.

Nu ben ik de opties aan het bekijken voor wat sata SSDs met een hardware raid controller in te prikken in de lan server. Echter, ik zat te denken, zou het niet voordeliger zijn om gewoon een moderne NVMe M2 van ergens 2 Terra in het systeem te prikken? Is qua bandbreedte geen probleem maar qua random read/writes kan ik dit niet zo goed inschatten.

Wat is de mening/ervaring hier exact?

[ Voor 7% gewijzigd door JacobsT op 08-09-2022 14:09 ]

[eheijnen]

Hier kun je wat meer over de snelheden lezen die je met een NVME M2 kunt halen.
https://www.enterprisesto...how-fast-are-nvme-speeds/

Lijkt me best een goede oplossing en redelijk kosten gunstig te doen ipv. van een hardware raid voor alleen wat downloads te doen. En dat via een Windows Share of Samba Share op Linux...

[ Voor 38% gewijzigd door eheijnen op 08-09-2022 14:38 ]

[JacobsT]

Ja daar ben ik van op de hoogte maar de vraag is of die snelheden enigszins doenbaar zijn mits er geen sequential read is van een gecachte game. Uiteindelijk zitten bv 7 computers niet op exact dezelfde bit te downloaden.

Gaat dus of het de moeite is om bv een raid controller te steken met bv 4 x SATA 870 1Tb EVO schijven in Raid 5/10 tov een gen4 2Tb NVME.

[ Voor 23% gewijzigd door JacobsT op 08-09-2022 14:38 ]

[DataGhost]

Een overweging die je daarbij kan maken is het gebruik van BitTorrent. Daarmee verlaag je zeker bij concurrent downloads de load op je "master" (die je ook kan laten super seeden) en de totale bandbreedte kan veel hoger worden, zeker binnen een enkel 4poorts switchje. Het is bij bijv. Steam games iets meer handmatig werk maar je kan daar prima het grootste deel van de gamedata neerzetten waarna je nog maar weinig online hoeft op te halen.

[ Voor 24% gewijzigd door DataGhost op 08-09-2022 14:41 ]

[eheijnen]

Persoonlijk zou ik geen Hardware RAID doen. Je bent ten allen tijden met een gesharde NVME sneller dan dat je download via het internet.

Als je files van 80GB gecached wil hebben dan zul je ook een RAID controller moeten hebben die zoveel cache memory heeft. Denk dat dat een erg heftig prijskaartje gaat worden.

[DataGhost]

eheijnen schreef op donderdag 8 september 2022 @ 14:43:
Persoonlijk zou ik geen Hardware RAID doen. Je bent ten allen tijden met een gesharde NVME sneller dan dat je download via het internet.

Als je files van 80GB gecached wil hebben dan zul je ook een RAID controller moeten hebben die zoveel cache memory heeft. Denk dat dat een erg heftig prijskaartje gaat worden.

Dat wordt prima gecached in RAM op een machine met 128GB ofzo, en dat valt qua prijs weer heel erg mee. Geen enkele reden dat die cache op de controller zou moeten zitten.

[eheijnen]

DataGhost schreef op donderdag 8 september 2022 @ 14:48:
[...]

Dat wordt prima gecached in RAM op een machine met 128GB ofzo, en dat valt qua prijs weer heel erg mee. Geen enkele reden dat die cache op de controller zou moeten zitten.

Ik refereer daar aan HW RAID waarover Ts het heeft.

[McKaamos]

eheijnen schreef op donderdag 8 september 2022 @ 14:43:
Persoonlijk zou ik geen Hardware RAID doen. Je bent ten allen tijden met een gesharde NVME sneller dan dat je download via het internet.

Als je files van 80GB gecached wil hebben dan zul je ook een RAID controller moeten hebben die zoveel cache memory heeft. Denk dat dat een erg heftig prijskaartje gaat worden.

Uhh, het hoeft niet in de cache van de controller te zitten hoor. Bij een NVMe drive staat t ook gewoon 'on disk'.
Je random access latencies moeten bij mechanische drives wel goed genoeg zijn, gezien er potentieel meerdere downloads tegelijk gedaan worden vanuit de cache.

Stel dat je een paar SATA SSD's pakt en die in een RAID set hangt, hardware of software, dan is dat ook een prima oplossing.
Een stapeltje oude SATA SSD's bij elkaar harken en aan elkaar knuppen, dikke prima voor zo'n cache. Snel zat.

eheijnen schreef op donderdag 8 september 2022 @ 14:50:
[...]

Ik refereer daar aan HW RAID waarover Ts het heeft.

dan nogsteeds niet. Je disk access moet snel genoeg zijn. Je gaat niet alles in een solidstate volatiele cache weten te proppen, ongeacht de storage oplossing.

[ Voor 15% gewijzigd door McKaamos op 08-09-2022 14:52 ]

[IceTeaGX]

Ga idd niet voor hardware RAID, kost meer, verbruikt meer, en snelheid win je er niet echt mee.
Software RAID kan wel een optie zijn, op een kleine dedicated server hiervoor. Een goede oplossing kan ook RAM caching doen. Je moet daarbij echt niet een volledig spel in RAM hebben zitten, gaat snel genoeg vanop SSD.
Met enkel SATA SSD zal je al zeer goede random performance hebben, NVME maakt vooral sequential reads sneller. Je kan ook meerdere NVME drives in software RAID plaatsen, als je compensatiedrang hebt.
En wat extra snelheid is mooi meegenomen, maar het belangrijkste lijkt me het ontladen van de internet verbinding.

14 man heeft echt niet zo veel nodig vanop een lan cache.

[DataGhost]

eheijnen schreef op donderdag 8 september 2022 @ 14:50:
[...]

Ik refereer daar aan HW RAID waarover Ts het heeft.

Onderliggende storage maakt geen drol uit voor OS cache. Al staat het op tape, als het gelezen is en in RAM staat, staat het daar en dan wordt bij volgende requests voor dezelfde data de controller niet eens meer aangesproken. Dus wat voor HW raid controller je hebt maakt niet uit voor caching. Het enige wat die controller-cache doet is wat meer systeem-RAM vrijhouden bij writes.

[JacobsT]

Via lancache zie je voldoende setups waar mensen optische drives koppelen met een NVME of RAM cache (in linux that is).

Ik wil sowieso een nette dedicated oplossing.
Gateway geeft de aangepaste DNS instellingen door aan alle clients en dan gaan alle steam/origin/battlenet/... downloads via de caching server. Is dus een setup die ook gewoon mag blijven draaien bij mij thuis.
Wil dus graag iets dat wel voldoende performantie heeft en 'deploy en forget' is.
Komt dus gewoon een vaste ubuntu machine voor lancache.

Torrents en heel dat gedoe wil ik absoluut niet gaan doen. Gewoon mensen vanuit steam app laten downloaden alsof ze het via internet zouden binnen trekken.

Consensus hier is dus om een NVMe M2 schijf met een 10gbit kaart gewoon te gebruiken en dat zou dan snel zat zijn? Er is ook een optie voor Sata SSD raid met 4 schijven en dan nog een NVME cache ertussen.
Budget is niet echt iets waar ik mee bezig ben zolang het natuurlijk acceptabel blijft. Wil er wel iets insteken maar ga nu ook geen lanserver zetten van meer dan 5000 euro

[ Voor 3% gewijzigd door JacobsT op 08-09-2022 14:57 ]

[McKaamos]

IceTeaGX schreef op donderdag 8 september 2022 @ 14:52:
Ga idd niet voor hardware RAID, kost meer, verbruikt meer, en snelheid win je er niet echt mee.
Software RAID kan wel een optie zijn, op een kleine dedicated server hiervoor. Een goede oplossing kan ook RAM caching doen. Je moet daarbij echt niet een volledig spel in RAM hebben zitten, gaat snel genoeg vanop SSD.
Met enkel SATA SSD zal je al zeer goede random performance hebben, NVME maakt vooral sequential reads sneller. Je kan ook meerdere NVME drives in software RAID plaatsen, als je compensatiedrang hebt.
En wat extra snelheid is mooi meegenomen, maar het belangrijkste lijkt me het ontladen van de internet verbinding.

14 man heeft echt niet zo veel nodig vanop een lan cache.

Of 14man dat wel of niet nodig heeft is natuurlijk de vraag. Als ze allemaal stomweg vergeten dat ze game X van 80GB klaar moeten hebben staan vooraf en allemaal tegelijk die game willen binnenharken...
Joah, dan kan ik me er wat bij voorstellen dat je een NVMe drive of een setje SATA drives in RAID wil hebben achter een 10Gbps link naar de switch.
Dan kan je iedereen voeden met ongeveer 700Mbps, wat grofweg 75MB/s is. Dan haal je 80GB binnen in 1066 seconden (~17min). Lijkt me acceptabel, als je ff gauw de game moet hebben. Kan nog wel vlotter...


edit: correctie aan de rekensom

[ Voor 8% gewijzigd door McKaamos op 08-09-2022 14:59 ]

[JacobsT]

McKaamos schreef op donderdag 8 september 2022 @ 14:57:
[...]

Of 14man dat wel of niet nodig heeft is natuurlijk de vraag. Als ze allemaal stomweg vergeten dat ze game X van 80GB klaar moeten hebben staan vooraf en allemaal tegelijk die game willen binnenharken...
Joah, dan kan ik me er wat bij voorstellen dat je een NVMe drive of een setje SATA drives in RAID wil hebben achter een 10Gbps link naar de switch.
Dan kan je iedereen voeden met ongeveer 700Mbps, wat grofweg 750MB/s is. Dan haal je 80GB binnen in 106 seconden. Lijkt me acceptabel, als je ff gauw de game moet hebben.

Dus jij gaat ervan uit dat een ubuntu machine met lancache, een 2Tb NVME gen4 schijf en een 10gbit NIC voldoende zijn dan? Ik weet dat het goedkoper kan maar ik ben en blijf natuurlijk ook een tweaker en hou wel van het nerden op performance

[IceTeaGX]

McKaamos schreef op donderdag 8 september 2022 @ 14:57:
[...]

Of 14man dat wel of niet nodig heeft is natuurlijk de vraag. Als ze allemaal stomweg vergeten dat ze game X van 80GB klaar moeten hebben staan vooraf en allemaal tegelijk die game willen binnenharken...
Joah, dan kan ik me er wat bij voorstellen dat je een NVMe drive of een setje SATA drives in RAID wil hebben achter een 10Gbps link naar de switch.
Dan kan je iedereen voeden met ongeveer 700Mbps, wat grofweg 750MB/s is. Dan haal je 80GB binnen in 106 seconden. Lijkt me acceptabel, als je ff gauw de game moet hebben.

Ik bedoel vooral dat 14 man niet zo'n zware load op de server zet, zelfs al moeten ze allemaal 160GB quasi tegelijk downloaden. Je clients moeten die snelheden ook nog kunnen volgen qua storage en CPU (decompression) Maakt het uit dat het dan 3 minuten duurt, als het er maar geen 30 zijn.

But if money is no concern: YouTube: We’re running out of internet - Steam Game Caching Server
Go bonkers

[McKaamos]

JacobsT schreef op donderdag 8 september 2022 @ 14:58:
[...]


Dus jij gaat ervan uit dat een ubuntu machine met lancache, een 2Tb NVME gen4 schijf en een 10gbit NIC voldoende zijn dan? Ik weet dat het goedkoper kan maar ik ben en blijf natuurlijk ook een tweaker en hou wel van het nerden op performance

10Gbps is ommenabij 1GB/s. Een fatsoenlijke NVMe drive doet gauw 3GB/s of meer. En gezien een solidstate drive geen last heeft verhoogde latencies door mechaniek, zal dat wel goed komen, idd.

Een stuk of 4 SATA SSD's van 500GB in RAID0 is ook een prima oplossing. Misschien iets meer last van latency, want dat zit ingebakken in het AHCI protocol.

IceTeaGX schreef op donderdag 8 september 2022 @ 15:01:
[...]


Ik bedoel vooral dat 14 man niet zo'n zware load op de server zet, zelfs al moeten ze allemaal 160GB quasi tegelijk downloaden. Je clients moeten die snelheden ook nog kunnen volgen qua storage en CPU (decompression) Maakt het uit dat het dan 3 minuten duurt, als het er maar geen 30 zijn.

But if money is no concern: YouTube: We’re running out of internet - Steam Game Caching Server
Go bonkers

True, 14man die gewoon koude data downloaden is geen enorme load. Het is gewoon data doorpompen, daar is geen rekenwerk voor nodig.

en ja, ik ken de video Altijd leuk, die over-the-top projecten.

[ Voor 34% gewijzigd door McKaamos op 08-09-2022 15:06 ]

[JacobsT]

IceTeaGX schreef op donderdag 8 september 2022 @ 15:01:
[...]
But if money is no concern: YouTube: We’re running out of internet - Steam Game Caching Server
Go bonkers

Kioxia drives zijn misschien beetje overkill en prijzig voor 14 man
Dacht dat zo een enkele drive richting 10k was hehe

McKaamos schreef op donderdag 8 september 2022 @ 15:03:
[...]

10Gbps is ommenabij 1GB/s. Een fatsoenlijke NVMe drive doet gauw 3GB/s of meer. En gezien een solidstate drive geen last heeft verhoogde latencies door mechaniek, zal dat wel goed komen, idd.

Een stuk of 4 SATA SSD's van 500GB in RAID0 is ook een prima oplossing. Misschien iets meer last van latency, want dat zit ingebakken in het AHCI protocol.

Ja ik wil misschien gerust de optie onderzoeken voor 2 NVME's in RAID te zetten maar ik zie daar dan minder het nut van in? Het zijn niet de throughput maar de random reads en requests en weet niet of raid daar dan perse bij zou helpen? Een PCIe insteek kaartje voor 2 tot 4 NVME schijven zal nog wel enigszins betaalbaar zijn denk ik.

[DataGhost]

Random reads zijn volgens mij best prima in RAID1, in theorie in ieder geval. Of je daar echt nog een insteekkaart voor nodig hebt hangt van je moederbord af. Dan zou ik ze gewoon in software RAID draaien.

[McKaamos]

JacobsT schreef op donderdag 8 september 2022 @ 15:07:
[...]


Kioxia drives zijn misschien beetje overkill en prijzig voor 14 man


[...]


Ja ik wil misschien gerust de optie onderzoeken voor 2 NVME's in RAID te zetten maar ik zie daar dan minder het nut van in? Het zijn niet de throughput maar de random reads en requests en weet niet of raid daar dan perse bij zou helpen? Een PCIe insteek kaartje voor 2 tot 4 NVME schijven zal nog wel enigszins betaalbaar zijn denk ik.

NVMe hoeft niet in RAID, als je er maar eentje neemt die vlot genoeg is.

SATA wil je wel in RAID, want anders haal je de max throughput niet.
De random read latencies worden niet echt geholpen door RAID, maar je kan het wel (gedeeltelijk) compenseren met extra throughput.

DataGhost schreef op donderdag 8 september 2022 @ 15:11:
Random reads zijn volgens mij best prima in RAID1, in theorie in ieder geval. Of je daar echt nog een insteekkaart voor nodig hebt hangt van je moederbord af. Dan zou ik ze gewoon in software RAID draaien.

Random read latencies op RAID 0/1 zijn zo snel als de traagste drive in de array.

[ Voor 19% gewijzigd door McKaamos op 08-09-2022 15:13 ]

[JacobsT]

McKaamos schreef op donderdag 8 september 2022 @ 15:11:
[...]

SATA wil je wel in RAID, want anders haal je de max throughput niet.
De random read latencies worden niet echt geholpen door RAID, maar je kan het wel (gedeeltelijk) compenseren met extra throughput.

Dit dacht ik dus.

Gewoon een dikke WD Black SN750 of SN770 NVME it is dus

[McKaamos]

JacobsT schreef op donderdag 8 september 2022 @ 15:14:
[...]


Dit dacht ik dus.

Gewoon een dikke WD Black SN750 of SN770 NVME it is dus

Yes, dat is de meest kosteneffectieve oplossing.
Tenzij je een handje vol Samsung 850 Evo's ergens in de kast hebt liggen, dan zou ik die in RAID smijten ipv een NVMe drive aan te schaffen.

Edit:
Moet je nagaan, vroeger stond er een webcache/proxy op elke LAN party... toen was websurfen een aanslag op de internet aansluiting met requests van enkele kilobytes per keer... Nu maken we ons zorgen over game downloads van gigabytes...

[ Voor 24% gewijzigd door McKaamos op 08-09-2022 15:17 ]

[DataGhost]

McKaamos schreef op donderdag 8 september 2022 @ 15:11:
[...]

Random read latencies op RAID 0/1 zijn zo snel als de traagste drive in de array.

Ik kan me voorstellen dat gelijktijdige random reads over de schijven verdeeld worden en je in theorie twee requests tegelijk kan afhandelen met dezelfde latency als één request op één schijf. Lager wordt het niet maar het gaat minder snel omhoog. Dat hangt natuurlijk wel volledig af van of de implementatie zulke balancing toepast.

[JacobsT]

Is dus een systeem met een 7400 CPU en een Prime Z270-P bord.
https://www.asus.com/Motherboards-Components/Motherboards/PRIME/PRIME-Z270-P/
Deze zou RAID ondersteunen voor de NVME.

Vraag me af of de CPU met die 4core afdoende gaat zijn maar dat zal wel meevallen I guess.

[IceTeaGX]

RAID support van het moederbord maakt niet echt uit. Doe het puur in software met ZFS, LVM, unraid, ...
Als je dat nog hebt liggen, kan je het er voor gebruiken. Een Z reeks moederbord is wat overkill, maar ja.

[McKaamos]

DataGhost schreef op donderdag 8 september 2022 @ 15:26:
[...]

Ik kan me voorstellen dat gelijktijdige random reads over de schijven verdeeld worden en je in theorie twee requests tegelijk kan afhandelen met dezelfde latency als één request op één schijf. Lager wordt het niet maar het gaat minder snel omhoog. Dat hangt natuurlijk wel volledig af van of de implementatie zulke balancing toepast.

Nee, zo werkt dat niet. In RAID wordt elke read in z'n geheel verdeeld over meerdere disks. Elke read (of write) raakt elke disk evenredig. En daardoor is de access latency zo snel als de traagste disk in de array.

Alleen als je JBOD draait is dat niet het geval. Maar je kan dan weer beargumenteren dat dat geen RAID is, want de R staat voor Redundant. En dan is RAID0 dus ook geen RAID, want eveneens geen redundantie.

[ Voor 14% gewijzigd door McKaamos op 08-09-2022 17:03 ]

[DataGhost]

McKaamos schreef op donderdag 8 september 2022 @ 16:59:
[...]

Nee, zo werkt dat niet. In RAID wordt elke read in z'n geheel verdeeld over meerdere disks. Elke read raakt elke disk evenredig. En daardoor is de access latency zo snel als de traagste disk in de array.

Alleen als je JBOD draait is dat niet het geval.

Bij controller X is dat misschien zo. Gelukkig kan je bijv. met software RAID1 de boel zo tunen dat je parallelle toegang over throughput prioriteert. Een fatsoenlijke scheduler zou dan gewoon onafhankelijke reads moeten doen van beide schijven tegelijk. Maar goed, dat wordt een beetje technisch en offtopic hier.

[McKaamos]

DataGhost schreef op donderdag 8 september 2022 @ 17:03:
[...]

Bij controller X is dat misschien zo. Gelukkig kan je bijv. met software RAID1 de boel zo tunen dat je parallelle toegang over throughput prioriteert. Een fatsoenlijke scheduler zou dan gewoon onafhankelijke reads moeten doen van beide schijven tegelijk. Maar goed, dat wordt een beetje technisch en offtopic hier.

Dan is het geen RAID meer maar praat je over iets als ZFS of iets anders fancy's
Al zou je dat statement ook weer anders kunnen beargumenteren.

[ Voor 5% gewijzigd door McKaamos op 08-09-2022 17:21 ]

[JacobsT]

Systeem draait intussen met een 10gbit NIC.

Beetje vreemde observatie.

Initial downloads van uncached games gaan echt tergend traag. Ergens 10-12mb/sec terwijl dit anders richting de 100Mb is.

De cache lijkt zijn werk wel te doen maar mijn 2.5Gb NIC raakt niet verzadigd en blijft steken rond de 170Mb/sec. Ik zie ook geen uitzonderlijke CPU loads en de NVME of geheugen kunnen vrijwel onmogelijk een bottleneck zijn.

De initial download lijkt me potentieel iets netwerk config related.
Ik ga alvast eens testen met wat additionele IPs toe te voegen zoals ze hier vermelden al lijkt me dit een vreemde oplossing:

In the event you find your initial download speed with the default settings is slow this may be resolved by allocating more IP’s to your cache. We suggest adding one IP at a time to see how much gain can be had (4 has been seen to work for a number of people). The most likely situation for this to help is in larger installs where you have a LAG network connection and are trying to balance many requests over multiple NICs.

https://lancache.net/docs...ache/#tweaking-slice-size

Voor de cached downloads, de 7400 CPU zou toch geen bottleneck mogen zijn voor een enkele computer die een download aan gaat?

[3DDude]

Wij spreken bij onze LAN (7 a 8 man) even af dat we de dagen ervoor even alle spellen downloaden enzo... XD (iedereen heeft glas / gig lol)
Lijkt me veel efficienter.

maar anders lekker tweetal NVME SSD'tjes gebruiken zeker als je die op 10gbit kan aansluiten is dat toch prima?

[ Voor 6% gewijzigd door 3DDude op 16-10-2022 23:37 ]

[McKaamos]

JacobsT schreef op zondag 16 oktober 2022 @ 23:20:
Systeem draait intussen met een 10gbit NIC.

Beetje vreemde observatie.

Initial downloads van uncached games gaan echt tergend traag. Ergens 10-12mb/sec terwijl dit anders richting de 100Mb is.

De cache lijkt zijn werk wel te doen maar mijn 2.5Gb NIC raakt niet verzadigd en blijft steken rond de 170Mb/sec. Ik zie ook geen uitzonderlijke CPU loads en de NVME of geheugen kunnen vrijwel onmogelijk een bottleneck zijn.

De initial download lijkt me potentieel iets netwerk config related.
Ik ga alvast eens testen met wat additionele IPs toe te voegen zoals ze hier vermelden al lijkt me dit een vreemde oplossing:


[...]


https://lancache.net/docs...ache/#tweaking-slice-size

Voor de cached downloads, de 7400 CPU zou toch geen bottleneck mogen zijn voor een enkele computer die een download aan gaat?

Heb je ook gekeken naar de storage en CPU van de downloadende client?
Steam games komen compressed binnen en kosten dus CPU voor de decompressie. Daar na moet t ook nog eens naar storage en als dat te traag is heb je ook een issue.

[JacobsT]

McKaamos schreef op maandag 17 oktober 2022 @ 10:00:
[...]

Heb je ook gekeken naar de storage en CPU van de downloadende client?
Steam games komen compressed binnen en kosten dus CPU voor de decompressie. Daar na moet t ook nog eens naar storage en als dat te traag is heb je ook een issue.

Is zeker het issue niet.
De client downloadt zonder de cache aan 110Mb/sec van Steam.
Betreft een 9900k met alle cores op 5.1Ghz en snel kitje DDR4 op een nvme m2.
Load daar is ook tijdens het downloaden zeer laag.

Het vreemde is dat ook de downloads initieel heel de tijd 180Mb/sec zijn van de cache en dan na 1 minuut droppen ze naar ergens 30Mb/sec. Zowel server als client hebben nul last van cpu/storage throttling.

Ook de initial download in de cache is echt extreem traag. Ergens 10-12Mb/sec.

Ik heb nog een threadripper 1950x systeem dat ik eventueel is wil testen om te kijken of het hardware related is maar heb zo een voorgevoel dat dit maar een beperkte impact gaat hebben aangezien de lancache CPU average rond de 20 percent blijft hangen.

[ Voor 12% gewijzigd door JacobsT op 17-10-2022 11:45 ]

[eheijnen]

Met iPerf kun je op je lan tussen 2 hosts de snelheid testen/meten.
https://iperf.fr/

Als dat goed gaat weet je dat het niet aan je netwerk / pc's ligt.

[JacobsT]

eheijnen schreef op maandag 17 oktober 2022 @ 11:57:
Met iPerf kun je op je lan tussen 2 hosts de snelheid testen/meten.
https://iperf.fr/

Als dat goed gaat weet je dat het niet aan je netwerk / pc's ligt.

Aha super, zeer goede test alvast.
Vrees wel dat het weldegelijk ergens aan de lancache hardware/config zal liggen.

Ik zie geen logische verklaring waarom het systeem anders eerst 1 tot 2 minuten aan 180mb kan downloaden om dan weg te zakken naar 30mb.

[eheijnen]

JacobsT schreef op maandag 17 oktober 2022 @ 12:03:
[...]
Aha super, zeer goede test alvast.
Vrees wel dat het weldegelijk ergens aan de lancache hardware/config zal liggen.

Ik zie geen logische verklaring waarom het systeem anders eerst 1 tot 2 minuten aan 180mb kan downloaden om dan weg te zakken naar 30mb.

Gaat er nu om dat je uitsluit dat het aan het netwerk/de pc's zelf ligt.
Als je 2 pc's met 10GB Nics hebt kun je die iPerf test ook op je 10GB segment draaien. Weet je dat ook gelijk.

[JacobsT]

eheijnen schreef op maandag 17 oktober 2022 @ 12:09:
[...]


Gaat er nu om dat je uitsluit dat het aan het netwerk/de pc's zelf ligt.
Als je 2 pc's met 10GB Nics hebt kun je die iPerf test ook op je 10GB segment draaien. Weet je dat ook gelijk.

Ik doe vanavond alvast even deze test en geef feedback.
Mijn logisch verstand maakt me echter wijs dat we bij een eventuele bottleneck daar nooit gedurende 1-2 minuten aan 180mb/sec zouden moeten kunnen downloaden.

Ik heb al her en der gelezen dat initial downloads van steam op de lancache soms traag kunnen zijn maar dat verklaart het rare gedrag niet met een gecachte game natuurlijk.

[eheijnen]

Klopt wat je zegt en is volkomen logisch. Maar meten is weten!

En als dat in zijn geheel duidelijk is weet je precies (of kom je dichterbij) waar je probleem zit.

[eheijnen]

En nog een beetje leesvoer:
https://lancache.net/docs/common-issues/

[JacobsT]

eheijnen schreef op maandag 17 oktober 2022 @ 12:21:
Klopt wat je zegt en is volkomen logisch. Maar meten is weten!

En als dat in zijn geheel duidelijk is weet je precies (of kom je dichterbij) waar je probleem zit.

Denk dat ik deze stap alvast even moet gaan bekijken.

Disabling systemd-resolved DNSStubListener
If your cache host is running a recent Linux distribution, it is likely running systemd-resolved, which listens on port 53. If you want your cache host to bind to 0.0.0.0:53 (INADDR_ANY, all IPv4 addresses), you will first need to disable systemd-resolved’s stub listener.

Run sudo -e /etc/systemd/resolved.conf and change the line starting with #DNSStubListener= to DNSStubListener=no - removing the # is important
Run sudo rm /etc/resolv.conf
Run sudo ln -s /var/run/systemd/resolve/resolv.conf /etc/resolv.conf
Run sudo service systemd-resolved restart
Check that you can still resolve DNS on the cache server by running nslookup for a domain of your choice (e.g. lancache.net)

Echter. een DNS issue zou toch in theorie los moeten staan van bandwidth issues? DNS is basically, either it resolves or it doesn't? Of zie ik dat verkeerd.

Alvast enorm bedankt voor de feedback en hulp.

[Ilmar]

JacobsT schreef op maandag 17 oktober 2022 @ 11:44:
[...]

Ik heb nog een threadripper 1950x systeem dat ik eventueel is wil testen om te kijken of het hardware related is maar heb zo een voorgevoel dat dit maar een beperkte impact gaat hebben aangezien de lancache CPU average rond de 20 percent blijft hangen.

Kijk ook eens naar verdeling over de cores. Dacht dat sommige (oudere) 10g drivers in bepaalde settings wel eens single-thread willen draaien of intern 1 limiterende queue-per-verbinding kunnen hebben. Ze zijn tenslotte vooral gemaakt om verkeer van veel verschillende clients af te handelen. Wellicht dat je er 1 voltrekt terwijl de rest niks staat te doen.

[JacobsT]

Ilmar schreef op maandag 17 oktober 2022 @ 12:37:
[...]


Kijk ook eens naar verdeling over de cores. Dacht dat sommige (oudere) 10g drivers in bepaalde settings wel eens single-thread willen draaien of intern 1 limiterende queue-per-verbinding kunnen hebben. Ze zijn tenslotte vooral gemaakt om verkeer van veel verschillende clients af te handelen. Wellicht dat je er 1 voltrekt terwijl de rest niks staat te doen.

Ook dit had ik bekeken. Load is vrijwel perfect gelijk gespreid over de 4 cores!

[eheijnen]

Nummertje 5 in die lijst met "Common Issues"gaat over slow download speeds.

Hou even mijn advies aan en test de zaken 1 voor 1. Als je meer dingen tegelijkertijd aanpast....

[JacobsT]

eheijnen schreef op maandag 17 oktober 2022 @ 11:57:
Met iPerf kun je op je lan tussen 2 hosts de snelheid testen/meten.
https://iperf.fr/

Als dat goed gaat weet je dat het niet aan je netwerk / pc's ligt.

Net even getest, bandbreedte lijkt alvast het issue niet te zijn.

[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 2.74 GBytes 2.35 Gbits/sec

[eheijnen]

Jah. Dat ziet er goed uit.

- Wat voor NVME disks heb je erbij geprikt en hoe zijn deze geconfigureerd?
- Voor welke raid ben je gegaan?
- Welke Linux versie gebruik je?

Ondertussen kun je nog eens met HTOP kijken wat er gebeurt op de machine als die lancache wordt aangesproken. Hier kun je goed CPU en Memory gebruik zien en kun je vrij simpel een indruk krijgen van de belasting.

[JacobsT]

eheijnen schreef op dinsdag 18 oktober 2022 @ 08:57:
Jah. Dat ziet er goed uit.

- Wat voor NVME disks heb je erbij geprikt en hoe zijn deze geconfigureerd?
- Voor welke raid ben je gegaan?
- Welke Linux versie gebruik je?

Ondertussen kun je nog eens met HTOP kijken wat er gebeurt op de machine als die lancache wordt aangesproken. Hier kun je goed CPU en Memory gebruik zien en kun je vrij simpel een indruk krijgen van de belasting.

Vanavond heb ik wat meer tijd. Dan ga ik rustig wat data verzamelen.

Zijn alvast geen raid setups. Zowel client als host hebben een enkele NVME drive die belast wordt.

[eheijnen]

Op https://lancache.net/ staan drie documentatie-onderwerpen met een link eronder:
System Overview, Monolithic en Lancache-DNS

Die dcos moet je ook nog eens goed doornemen.

[JacobsT]

eheijnen schreef op dinsdag 18 oktober 2022 @ 20:48:
Op https://lancache.net/ staan drie documentatie-onderwerpen met een link eronder:
System Overview, Monolithic en Lancache-DNS

Dat dcos moet je ook nog eens goed doornemen.

Alweer wat verder:
Lancache op threadripper.
Was probleem met schijfpermissie, dat is intussen opgelost.

Het probleem situeert zich nu vooral met controle via dstat.

Er is een ongezien hoog aantal interrupts en dat laat het boeltje in de soep draaien.
Zit met een Ubiquiti Dream Machine gateway, heb DPI enz allemaal uitgeschakeld maar slaag er niet meteen in het probleem te pinpointen.



Zoals je kan zien, het systeem zelf verroert geen ene moer. Het is zuiver te wijten aan de onverklaarbare interrupts die extreem spiken.

[eheijnen]

Ik heb hier bij mij geen problemen met een machine die behoorlijke interrupt waarden heeft terwijl er VMs op draaien en nog wat andere zaken. Niet zeker of dat een probleem is...

Heb je bij het testen met een client ook de client DNS server aangepast zodat die naar de lancache server wijst. De documentatie wijst hier nadrukkelijk op en legt ook uit waarom dit een cruciaal onderdeel is van het fucntioneren.

Als je de lancache aanspreekt zodat die zaken voor je gaat ophalen worden deze dan ook op de nvme schijf gezet?

Ook als je clients DHCP gebruiken kun je toch de DNS handmatig aanpassen. Dit lijkt me de beste oplossing en anders moet je lancache server altijd hebben aanstaan.
Je kunt het DNS IP voor de LAN Party natuurlijk ook in de router aanpassen en na afloop weer terugzetten...op die manier hoeven de gasten niets aan te passen.

Neem de documentatie goed door zodat je vertrouwt raakt met Lancache. Daar zul je zeker nog wat aan hebben als er met een party een wat misgaat. Pas dan zul je wat meer inzicht krijgen hoe de performance is en daar kun je dan na de party weer mee aan de slag om te kijken of dat beter kan.

[JacobsT]

eheijnen schreef op woensdag 19 oktober 2022 @ 11:22:
Ik heb hier bij mij geen problemen met een machine die behoorlijke interrupt waarden heeft terwijl er VMs op draaien en nog wat andere zaken. Niet zeker of dat een probleem is...

Heb je bij het testen met een client ook de client DNS server aangepast zodat die naar de lancache server wijst. De documentatie wijst hier nadrukkelijk op en legt ook uit waarom dit een cruciaal onderdeel is van het fucntioneren.

Als je de lancache aanspreekt zodat die zaken voor je gaat ophalen worden deze dan ook op de nvme schijf gezet?

Ook als je clients DHCP gebruiken kun je toch de DNS handmatig aanpassen. Dit lijkt me de beste oplossing en anders moet je lancache server altijd hebben aanstaan.
Je kunt het DNS IP voor de LAN Party natuurlijk ook in de router aanpassen en na afloop weer terugzetten...op die manier hoeven de gasten niets aan te passen.

Neem de documentatie goed door zodat je vertrouwt raakt met Lancache. Daar zul je zeker nog wat aan hebben als er met een party een wat misgaat. Pas dan zul je wat meer inzicht krijgen hoe de performance is en daar kun je dan na de party weer mee aan de slag om te kijken of dat beter kan.

- DNS van de client staat als enige primary op cachehost
- nvme schijf krijgt idd data erop
- interrupts zijn niet normaal, heb met iemand op discord in de lancachegroep gesproken en die wees me hier ook op. zodra de interrupts spiken, tankt de snelheid

Er loopt weldegelijk echt iets mis. Ik begin eerder in de richting van de ubiquiti dream machine te denken die one way or another roet in het eten gooit.

[eheijnen]

Dan eerst even terug naar netwerk testen om te kijken of die router een probleem heeft.
Je kunt daarvoor een publieke Iperf Server gebruiken en kijken hoe die performed binnen een wat langere periode, laten we zeggen 15 minuten.
Wel zorgen dat de client DNS IP naar de router wijst.

Als lancache problemen heeft met de router dan zou ik zeggen dat een client dat ook zou moeten hebben.

Wat zei die persoon over hoe die interrupt waarden eruit zouden moeten zien?

[eheijnen]

En post eens de regel uit de fstab waarmee dat nvme volume gemount word...

[ Voor 3% gewijzigd door eheijnen op 19-10-2022 12:32 ]

[JacobsT]

Ik heb gisteren dus nog stevig wat doorgetest.

Paar observaties en resultaten:
- Heb UDM Pro Gateway uit het netwerk gehaald. Resultaten blijven hetzelfde. Gateway lijkt het alvast niet te zijn
- Lancache blijft traag downloaden. Heb een prefill tool gebruikt lokaal op de cachehost waarbij deze direct van steam download om uit te sluiten dat het bij initial downloads ergens door netwerkconfiguratie mis liep in de communicatie tussen client en host. Snelheid blijft ongeveer 25% van de capaciteit van de lijn. Om uit te sluiten dat het toch ergens aan de host lag, heb ik dan ook even de normale steam client geinstalleerd en deze haalt wel de normale lijnsnelheden

Ik heb dan ook in de error logs liggen pluizen en daar krijg ik onnoemelijk veel timeouts wanneer ik prefill via de host zelf. Mijn gevoel zegt op basis van aantal zaken die ik lees, dat for some reason de lancache een flood aan DNS requests doet en dit zorgt voor timeouts en throttling.

https://blenderfox.com/20...peeds-on-steam-for-linux/

Er zou een lichtpuntje zijn met dit script te installeren maar daar slaag ik met mijn beperkte linux kennis tot dusver niet in.

https://github.com/uklans/cache-domains/tree/master/scripts

[eheijnen]

Had ik ook gedacht dat het netwerk verder OK is. Maar nu weet je dat zeker en kom je bij lancache zelf uit, waarmee de rest uitgesloten is. Als die lancache al op grote Lan-parties gebruikt wordt dan moet het goed werken en zou ik zeggen dat het om een configuratiefout gaat.

Gaan we eens wat dieper spitten:

• Vertel eens hoe je die lancache geïnstalleerd en geconfigureerd hebt?
• Welke Linux versie gebruik je?
• Post eens de regel uit de /etc/fstab waarmee dat nvme volume gemount word
• Post eens een gedeelte van die time-outs uit de logging waar je het over had tijdens de prefill
• Die vloed aan DNS requests is dat een aanname of is daar feitelijke info over?
• Is er op die machine een DNS server actief buiten de Lancache om? (zoals Bind b.v.)

[ Voor 6% gewijzigd door eheijnen op 21-10-2022 12:44 ]

[querex]

JacobsT schreef op vrijdag 21 oktober 2022 @ 10:43:
Lancache blijft traag downloaden. Heb een prefill tool gebruikt lokaal op de cachehost waarbij deze direct van steam download om uit te sluiten dat het bij initial downloads ergens door netwerkconfiguratie mis liep in de communicatie tussen client en host. Snelheid blijft ongeveer 25% van de capaciteit van de lijn. Om uit te sluiten dat het toch ergens aan de host lag, heb ik dan ook even de normale steam client geinstalleerd en deze haalt wel de normale lijnsnelheden

Ik was met volle interesse aan het lezen naar de oorzaak / oplossing.
Maar die ontbreekt nog, hoe is het uiteindelijk afgelopen?
Bedankt!

[GarBaGe]

Ik weet niet of dit nog een courant probleem is.
Steam kan tegenwoordig ook downloaden over lokaal netwerk van andere steam gebruikers:
https://help.steampowered.../view/46BD-6BA8-B012-CE43