'Fujitsu's op udp gebaseerd netwerkprotocol is tot 30 keer zo snel als tcp'
Fujitsu heeft naar eigen zeggen een nieuw en propriëtair transmissieprotocol ontwikkeld op basis van udp dat ten opzichte van tcp tot dertigmaal hogere doorvoersnelheden mogelijk maakt. Ook de latency zou fors verlaagd kunnen worden.
Het nieuwe protocol maakt gebruik van de sterke punten van udp, een netwerkprotocol dat gebruikt wordt voor toepassingen als streaming media en online gaming. Udp weet gemiddeld hogere snelheden te behalen dan tcp, maar het protocol beschikt niet over een mechanisme voor het opnieuw versturen van datapakketjes als deze niet aankomen op de plek van bestemming.
Fujitsu stelt dat zijn nog naamloze protocol de latency van tcp bij het opnieuw versturen van data bij slechte dataverbindingen sterk kan reduceren. Dit zou mogelijk zijn doordat het protocol een eigen controlemechanisme heeft en op hoge snelheid onderscheid zou kunnen maken tussen lost packets en pakketjes die nog niet zijn gearriveerd op de plek van bestemming.
Fujitsu claimt dat tijdens tests met het versturen van bestanden tussen Japan en de VS snelheidswinsten met een factor 30 zijn behaald. Bij het gebruiken van virtuele desktops over dezelfde verbinding zou de latency slechts 1/6 bedragen ten opzichte van eerder gemeten niveaus.
Het protocol zou als software-uitbreiding boven op een udp-stack kunnen draaien. Verder claimt Fujitsu dat een groot aantal internettoepassingen die gebruikmaken van tcp zonder verdere aanpassingen gebruik kan maken van het nieuwe protocol. Het Japanse bedrijf wil zijn netwerkprotocol aan andere bedrijven gaan verkopen in de vorm van middleware.
Reacties (68)
Propriëtair: betekent dit dan in de realiteit dat dit alleen bruikbaar is bij Fujitsu-apparaten onderling, of zouden ook andere fabrikanten dit gaan implementeren (al dan niet tegen licentie)?
Ik snap dat R&D geld kost en dat ze dit terug willen zien maar je hoort vaker van nieuwe protocollen die nooit aan de man komen. Zelfs 'open' standaarden en protocollen doen er jaren over om een beetje geaccepteerd te worden.
Ik snap dat R&D geld kost en dat ze dit terug willen zien maar je hoort vaker van nieuwe protocollen die nooit aan de man komen. Zelfs 'open' standaarden en protocollen doen er jaren over om een beetje geaccepteerd te worden.
[Reactie gewijzigd door Passeridae op woensdag 30 januari 2013 13:40]
Het Japanse bedrijf wil zijn netwerkprotocol aan andere bedrijven gaan verkopen in de vorm van middleware.
Ik kan wel lezen maar ik zeg juist "
Ik begrijp dat het hun wens is maar hoe vaak zal dit in de praktijk gebeuren waarbij je op grote schaal dit als consumenten in producten verwerkt gaat zien worden.
".dan in de realiteit
Ik begrijp dat het hun wens is maar hoe vaak zal dit in de praktijk gebeuren waarbij je op grote schaal dit als consumenten in producten verwerkt gaat zien worden.
op zich zou een licentiemodel toch wel acceptabel zijn?
en een 30x snelheids toename is wel erg veel, nou is dat wss natuurlijk het meest gunstige geval, maar het blijft een enorme winst.
ben benieuwd wat hier verder mee gaat gebeuren. ook interessant voor mogelijk 3g/4g internet of zie ik dat fout, lagere latency en snellere errorcorrectie is daar vooral erg nuttig lijkt me, (op elk draadloos netwerk eigenlijk)
en een 30x snelheids toename is wel erg veel, nou is dat wss natuurlijk het meest gunstige geval, maar het blijft een enorme winst.
ben benieuwd wat hier verder mee gaat gebeuren. ook interessant voor mogelijk 3g/4g internet of zie ik dat fout, lagere latency en snellere errorcorrectie is daar vooral erg nuttig lijkt me, (op elk draadloos netwerk eigenlijk)
Als dit een niche-oplossing blijft wel, maar als ze het grootschalig geaccepteerd willen zien als een nieuwe standaard dan moet het een open standaard zijn, zonder licentiekosten en zonder kosten voor patenten van derden.op zich zou een licentiemodel toch wel acceptabel zijn?
Het transport-level protocol voor het internet is domweg te belangrijk voor de rest van de wereld om iets anders te accepteren. (bijv: Cisco wil Fujitsu niet tot in de lengte van dagen betalen, Open source systemen kunnen het dan niet implementeren, etc)
De rest van de wereld zal er dan waarschijnlijk voor kiezen om gezamenlijk een concurrerend protocol te ontwikkelen dat hetzelfde doet.
Maar hoe handelt hij dan de "lost packages" of is "lost" gewoon lost...?
UDP doet daar dus niet aan het stuurt data over een verbinding en of er nu wel of niet geluisterd wordt maakt niet uit. Ik gebruik het veel in industriële omgevingen , voor data die niet heel erg belangrijk is omdat het minder storings gevoelig is.
voor uren tellers en counters die gelogd moeten worden ...
tja je zou het misschien wel kunnen in bouwen aan de ontvangende kant
dat de computer zelf bij houd welke pakketjes aan komen en als er iets mist zou de aan de zendende computer kunnen vragen het nogmaals te versturen
dat genererend natuurlijk veel minder data..
voorbeeld tcp/ip
Ik heb een pak met 100 rietjes en jij wil het pak met rietjes hebben
we onderhandelen en ik stuur 1 rietje per keer naar je op via de post jij stuurt mij een brief terug van ontvangen stuur de volgende maar op. dit gaan we net zo lang doen tot jij alle rietjes hebt... best wel een tijds verspilling niet?
UDP
Idem maar nu stuur de in 1 keer de doos met de 100 rietjes op. Ik heb er geen track en trace op gedaan dus we zien wel of het aan komt.
Het zou fijn zijn als de nieuwe standaard dus zegt van
ik heb de doos binnen gekregen maar ik mis 2 rietjes stuur mij die even na.
dat scheelt heel veel data of we zouden standaard correctie bits moeten versturen en als we dus met films doen (par2 files is een voorbeeld)
voor uren tellers en counters die gelogd moeten worden ...
tja je zou het misschien wel kunnen in bouwen aan de ontvangende kant
dat de computer zelf bij houd welke pakketjes aan komen en als er iets mist zou de aan de zendende computer kunnen vragen het nogmaals te versturen
dat genererend natuurlijk veel minder data..
voorbeeld tcp/ip
Ik heb een pak met 100 rietjes en jij wil het pak met rietjes hebben
we onderhandelen en ik stuur 1 rietje per keer naar je op via de post jij stuurt mij een brief terug van ontvangen stuur de volgende maar op. dit gaan we net zo lang doen tot jij alle rietjes hebt... best wel een tijds verspilling niet?
UDP
Idem maar nu stuur de in 1 keer de doos met de 100 rietjes op. Ik heb er geen track en trace op gedaan dus we zien wel of het aan komt.
Het zou fijn zijn als de nieuwe standaard dus zegt van
ik heb de doos binnen gekregen maar ik mis 2 rietjes stuur mij die even na.
dat scheelt heel veel data of we zouden standaard correctie bits moeten versturen en als we dus met films doen (par2 files is een voorbeeld)
[Reactie gewijzigd door Red_inc op woensdag 30 januari 2013 19:26]
Idee:
Je kan ook met errorcorrectie (ala DVD) de data opzich zodanig redundant maken dat je de missende paketjes can reconstrueren.
Dan hoef je helemaal niets meer te hersturen en is het alleen problematisch als er zoveel niet aankomt dat het reconstrueren ook niet meer lukt.
En dan ben je inderdaad van die hele handshake af.
Je kan ook met errorcorrectie (ala DVD) de data opzich zodanig redundant maken dat je de missende paketjes can reconstrueren.
Dan hoef je helemaal niets meer te hersturen en is het alleen problematisch als er zoveel niet aankomt dat het reconstrueren ook niet meer lukt.
En dan ben je inderdaad van die hele handshake af.
[Reactie gewijzigd door trogdor op woensdag 30 januari 2013 23:11]
Dat werkt niet als je maar weinig data (een pakketje) te versturen hebt.
Het versturen van deze correctie-data (PAR) is gewoon extra data. De overhead daarmee is dus ENORM!
Hoezo minder data ?tja je zou het misschien wel kunnen in bouwen aan de ontvangende kant
dat de computer zelf bij houd welke pakketjes aan komen en als er iets mist zou de aan de zendende computer kunnen vragen het nogmaals te versturen
dat genererend natuurlijk veel minder data..
Wat je daar beschrijft, is wat TCP doet. De overhead van TCP is 20 bytes per segment. (En een segment kan (praktisch) zo'n 1400 bytes lang zijn. Dat is ongeveer 1% overhead (in packetsize). Ga je dat beter doen met je eigen protocol ?
Gelukkig hebben we een "sliding window" in TCP. Van 64k (of groter, met nieuwere, gestandariseerde extensies). TCP zend dus een hoop rietjes achter elkaar, voordat het wacht op een ack.voorbeeld tcp/ip
Ik heb een pak met 100 rietjes en jij wil het pak met rietjes hebben
we onderhandelen en ik stuur 1 rietje per keer naar je op via de post jij stuurt mij een brief terug van ontvangen stuur de volgende maar op. dit gaan we net zo lang doen tot jij alle rietjes hebt... best wel een tijds verspilling niet?
Dat bestaat al. In TCP. En heet "selective ack (SACK)".Het zou fijn zijn als de nieuwe standaard dus zegt van
ik heb de doos binnen gekregen maar ik mis 2 rietjes stuur mij die even na.
dat scheelt heel veel data of we zouden standaard correctie bits moeten versturen en als we dus met films doen (par2 files is een voorbeeld)
RFC 2018 uit 1996: http://www.hjp.at/doc/rfc/rfc2018.txt
RFC 2883 uit 2000: http://tools.ietf.org/html/rfc2883
Mensen hebben altijd kritiek op TCP. Dat het traag zou zijn. Dat het veel overhead heeft. Maar als ze dan zelf beginnen met een eigen transport protocol te ontwikkelen, dan blijkt na een tijdje dat ze alle features uit TCP hebben nagebouwd. En dus net zo veel "overhead" hebben.
Alleen als je voor specifieke applicaties een nieuw transport protocol wilt bouwen, dan heb je kans van slagen. Als je een general purpose reliable transport protocol wilt maken, voor zowel grote files als korte transacties, of interactief werk, dan is TCP een uitstekende keuze.
Dit protocol van Fijutsu heeft zich toegelegd op situaties waar je veel packet drops hebt. Tegenwoordig is dat vrij zeldzaam, behalve bij drukke WiFi netwerken. En zelfs dan hangt het er nog maar vanaf. Een maand of wat geleden was er hier een soortgelijk artikel over een ander protocol voor WiFi (met drops). Daar bleek dat de onderzoekers hun protocol hadden vergeleken met TCP zonder SACK. Tsja, dan lijkt het allicht beter dan de TCP van voor 1996.
De doelstelling van Fujitsu zal zijn om er geld mee te verdienen, ze begrijpen zelf ook wel dat ze hiermee niet het internet gaan veroveren.
Het kan bovenop de huidige protocollen verwerkt worden, het is dus gewoon optioneel.
tcp en upd liggen zo vast idem moet alle router dat ze sowieso moeilijk vervangen kunnen worden. Maar we zullen zien of de markt dit wil betalen.
tcp en upd liggen zo vast idem moet alle router dat ze sowieso moeilijk vervangen kunnen worden. Maar we zullen zien of de markt dit wil betalen.
M.a.w. voor intra-continentale verbindingen zie je geen verbetering, als ik het juist interpreteer ? (Intra-continentaal as in: tussen België en Duitsland bvb.)
Want dan loopt de grafiek gelijk met tcp, wat mij doet aannemen dat in dat geval udp sneller is dan zowel tcp als dit nieuwe protocol. Sterker nog, dan is dit nieuwe protocol zelfs niet sneller dan tcp, wat dan weer opmerkelijk is !
Want dan loopt de grafiek gelijk met tcp, wat mij doet aannemen dat in dat geval udp sneller is dan zowel tcp als dit nieuwe protocol. Sterker nog, dan is dit nieuwe protocol zelfs niet sneller dan tcp, wat dan weer opmerkelijk is !
[Reactie gewijzigd door Spatlap op woensdag 30 januari 2013 13:38]
Nee, daar is ook verbetering, maar de grootte daarvan is lager.
Kijjk maar naar de grafieken, het gedeelte "within Japan" laat toch nog steeds verbetering zien.
Daarnaast gaat het niet zozeer over internationaal/intercontinentaal, maar over de 'lengte' van het netwerk en de kans op packetloss. Juist op dat punt zit de verbetering, dus die is het grootst op netwerken met veel packet loss en dat is meestal de meest verre verbinding.
Kijjk maar naar de grafieken, het gedeelte "within Japan" laat toch nog steeds verbetering zien.
Daarnaast gaat het niet zozeer over internationaal/intercontinentaal, maar over de 'lengte' van het netwerk en de kans op packetloss. Juist op dat punt zit de verbetering, dus die is het grootst op netwerken met veel packet loss en dat is meestal de meest verre verbinding.
De grootste winst van dit protocol is wanneer een pakketje verloren raakt, hoe groter de afstand, hoe groter de kans dat dit gebeurt. Op je lokale netwerk zal het dus 0 nut hebben, maar tussen landen misschien al wel een beetje.
Het protocol gaat beter om met high latency / high package-loss verbindingen. OF eigenlijk beter gezegd TCP gaat er heel slecht mee om. Deze problemen worden uitvergroot wanneer de verbindingen sneller worden. De afgelopen 10 jaar zijn er heel wat papers uitgekomen met oplossingen ik vermoed dat een aantal van deze zijn gecombineerd en geïmplementeerd.
http://fasterdata.es.net/...ing/tcp-issues-explained/ beschrijft een deel van de problemen.
http://fasterdata.es.net/...ing/tcp-issues-explained/ beschrijft een deel van de problemen.
Zo zijn er wel meer protocollen die UDP gebruiken, bijvoorbeeld FASP van Asperasoft: http://asperasoft.com/technology/transport/fasp/
Dit protocol is naar mijn begrijpen geen een die gebruik maakt van UDP, maar een alternatief voor UDP (en TCP).
Het is een alternatief voor TCP dat geïmplementeerd is middels UDP.
udp is van nature veel sneller dan tcp. Immers worden er geen ack's teruggestuurd waarop gewacht moet worden. De hogere lagen moeten dan echter wel voor de juiste checksum e.d. zorgen anders komen de bestanden verminkt over.
ER zijn ook applicaties waarbij dat niet uitmaakt. Voice of Video bijvoorbeeld is het beter om een hikje te ervaren dan een retransmit waarbij het hele beeld stilstaat. Ook bij realtime uitzendingen wordt veelal udp gebruikt omdat men niet op de ack's van de buren wil wachten.
ER zijn ook applicaties waarbij dat niet uitmaakt. Voice of Video bijvoorbeeld is het beter om een hikje te ervaren dan een retransmit waarbij het hele beeld stilstaat. Ook bij realtime uitzendingen wordt veelal udp gebruikt omdat men niet op de ack's van de buren wil wachten.
Misschien tijd dat iemand het concept "sliding window" uitvindt.udp is van nature veel sneller dan tcp. Immers worden er geen ack's teruggestuurd waarop gewacht moet worden.
Was mooi geweest als ze UDP ook in de vergelijking hadden meegenomen
Zat ik dus ook te denken. Dit is een beetje dat je een auto, die op een ferrari is gebaseerd ga vergelijken met een lada.
Dat is in dit geval een beetje zinloos.
Een video streamen via UDP is prima, omdat packetloss niet uitmaakt.
In dit geval wil je wel een vergelijking tussen protocollen die wel een garantie bieden op wat er binnenkomt.
Probeer maar een versleuteld bestand via UDP te verzenden en kijk of je het aan de andere kant nog kan ontsleutelen.
Een video streamen via UDP is prima, omdat packetloss niet uitmaakt.
In dit geval wil je wel een vergelijking tussen protocollen die wel een garantie bieden op wat er binnenkomt.
Probeer maar een versleuteld bestand via UDP te verzenden en kijk of je het aan de andere kant nog kan ontsleutelen.
Overigens kan dit best, maar dan zal je in de applicatielaag extra overhead moeten toevoegen. Het zal niet efficiënter zijn dan meteen TCP toepassen, maar het kan.
Dat lijkt me ook precies wat fujitsu heeft uitgewerkt. Applicatie level controle, daaronder gebruiken ze gewoon UDP.
Dus dit is geen netwerkprotocol maar een applicatieprotocol, het netwerkprotocol is gewoon UDP.
Zoals al eerder gezegd komen er wel meer van dit soort dingen langs, vaak ontwikkeld door partijen die een applicatie bieden die zowel lage latency als betrrouwbaarheid vereisen. Daarmee zal het dus concurreren, niet met TCP of UDP.
Dus dit is geen netwerkprotocol maar een applicatieprotocol, het netwerkprotocol is gewoon UDP.
Zoals al eerder gezegd komen er wel meer van dit soort dingen langs, vaak ontwikkeld door partijen die een applicatie bieden die zowel lage latency als betrrouwbaarheid vereisen. Daarmee zal het dus concurreren, niet met TCP of UDP.
Als je heel precies wilt zijn, dan is het ook geen applicatie protocol. Een applicatie protocol is een protocol dat binnen in de applicatie wordt geprogrammeerd. Dat is dit niet. (HTTP is een soort applicatie protocol). Dit nieuwe protocol wordt (kant-en-klaar) gebruikt door de applicatie. Het is een soort "middle-ware". Tussen de applicatie en het OS in.
IP is een netwerk protocol. Ik durf zelfs te stellen: IP is het netwerk protocol.
UDP zit daar een laag boven. UDP is een transport protocol. (Net als TCP).
Dit nieuwe protocol zit daar weer boven.
De best naam, imho, zou zijn: dit is een soort session-protocol.
(Netjes volgens het OSI model. Maar zelfs dan voldoet het waarschijnlijk niet aan de voorwaarden die het OSI model stelt aan een session-protocol. Bv omdat we in de IP wereld geen echte EndPoint-Indentifiers hebben (alleen interface-addressen)).
IP is een netwerk protocol. Ik durf zelfs te stellen: IP is het netwerk protocol.
UDP zit daar een laag boven. UDP is een transport protocol. (Net als TCP).
Dit nieuwe protocol zit daar weer boven.
De best naam, imho, zou zijn: dit is een soort session-protocol.
(Netjes volgens het OSI model. Maar zelfs dan voldoet het waarschijnlijk niet aan de voorwaarden die het OSI model stelt aan een session-protocol. Bv omdat we in de IP wereld geen echte EndPoint-Indentifiers hebben (alleen interface-addressen)).
[Reactie gewijzigd door gryz op donderdag 31 januari 2013 00:55]
Nee want dan vergelijk je een protocol dat niets doet met verloren pakketten met een protocol dat er voor zorgt dat alles altijd aankomt. Appels en peren dus.
UDP is ook gebruikt bij gaming?
Ik kan niet precies aflezen of je statement wel of niet als vraag bedoeld is, maar ja. Bij gaming is het (afhankelijk van de game) van belang dat je pakketjes snel binnenkrijgt. Als er een pakketje mist is hertransmissie weinig zinnig, je bent dan immers al weer verderop in de game dus een geretransmit stukje informatie over, bijvoorbeeld, de locatie van andere spelers heeft geen zin meer, als dat aankomt is die locatie alweer ververst door nieuwere informatie.
Hangt wel sterk van de game af natuurlijk, een shooter is hier gevoeliger voor dan een MMORPG ofzo.
Hangt wel sterk van de game af natuurlijk, een shooter is hier gevoeliger voor dan een MMORPG ofzo.
Dit is zeer interessante voor thuis toepassingen.
Bij het lezen van dit artikel dacht ik direct aan de troughput van mijn NAS (eigen bouw o.b.v. atom) wat nu gelimiteerd wordt door TCP ( gemiddelde troughput van 108 MB/s) op een gigabit aansluiting.
Ik zou dit zeker uit willen proberen binnen mijn thuis netwerk, indien dit beschikbaar komt.
Bij het lezen van dit artikel dacht ik direct aan de troughput van mijn NAS (eigen bouw o.b.v. atom) wat nu gelimiteerd wordt door TCP ( gemiddelde troughput van 108 MB/s) op een gigabit aansluiting.
Ik zou dit zeker uit willen proberen binnen mijn thuis netwerk, indien dit beschikbaar komt.
Dat zal dan bijna niks uitmaken, binnen je thuisnetwerk heb je echt geen last van packet loss en/of latency waardoor tcp relatief langzaam kan zijn.
Je throughput wordt gelimiteerd door je Gb aansluiting, niet door TCP. 108 MB/s gemiddeld zit aardig in de buurt van de limiet.
108 Megabyte/s is > 800Megabits/s dus aardig in de buurt van 1 Gigabit.
Nee. De latency die die paar hops in je huis met die minimale kabelafstanden oplevert ga je niet drastisch kunnen verlagen. Dan heb je het over een totaallatency van een paar milliseconden.
Als je een pad van 20 hops over de halve wereld hebt met in totaal 600ms latency heb je hier wellicht wat aan. Maar dan nog is het alleen zinnig voor een applicatie die en latencygevoelig is en hoge betrouwbaarheid eist. En je moet het niet simpel binnen je applicatie kunnen oplossen voordat je middleware van een derde inzet.
Een gemiddelde throughput tussen NAS en PC van 108MB, en dus 864Mbit is erg netjes voor een thuisoplossing hoor. Daar gaat dit niet bij helpen. Wellicht dat je sessie iets sneller groeit naar die maximale throughput maar ook daar zou ik niet op rekenen in kleine netwerken op korte afstanden.
Als je een pad van 20 hops over de halve wereld hebt met in totaal 600ms latency heb je hier wellicht wat aan. Maar dan nog is het alleen zinnig voor een applicatie die en latencygevoelig is en hoge betrouwbaarheid eist. En je moet het niet simpel binnen je applicatie kunnen oplossen voordat je middleware van een derde inzet.
Een gemiddelde throughput tussen NAS en PC van 108MB, en dus 864Mbit is erg netjes voor een thuisoplossing hoor. Daar gaat dit niet bij helpen. Wellicht dat je sessie iets sneller groeit naar die maximale throughput maar ook daar zou ik niet op rekenen in kleine netwerken op korte afstanden.
(en ook @ mensen boven me)
Vergeet het verschil tussen megabyte en mebibyte niet, he! File transfers worden over het algemeen altijd gemeten in mebibyte/s oftewel MiB/s.
Een Gigabit verbinding heeft een throughput van 1 miljard bits/s. Het maximaal haalbare is dan ook 1.000.000.000 / 8 / 1.024 / 1.024 = ~119,2 MiB/s, maar dat is bruto (dus inclusief overhead van de packets zelf)
Met een throughput van 108MiB/s zit je al aan de 108 * 1.024 * 1.024 * 8 / 1.000.000 = ~906 Mbps netto (dus zónder overhead).
Vergeet het verschil tussen megabyte en mebibyte niet, he! File transfers worden over het algemeen altijd gemeten in mebibyte/s oftewel MiB/s.
Een Gigabit verbinding heeft een throughput van 1 miljard bits/s. Het maximaal haalbare is dan ook 1.000.000.000 / 8 / 1.024 / 1.024 = ~119,2 MiB/s, maar dat is bruto (dus inclusief overhead van de packets zelf)
Met een throughput van 108MiB/s zit je al aan de 108 * 1.024 * 1.024 * 8 / 1.000.000 = ~906 Mbps netto (dus zónder overhead).
Tuurlijk. Want 108 MegaByte/sec halen over een 1 Gbps netwerk is wel erg slecht. Dit nieuwe protocol is wel 30x sneller. Dus dan kun je mooi 3240 MegaByte/sec halen ! Feest !
Zonder dollen: 108 MBps = 864 Mbps = 0.864 Gbps. Als je in gedachten houdt dat je altijd wat overhead hebt door protocol headers (minimaal 58 bytes voor iedere 1460 bytes aan data = 3.8%), dan zit je al aardig bij de maximale haalbare snelheid. Ik snap niet waar je over klaagt. Ik zou ook eerst eens kijken dan de bottleneck van je HDD (of zelfs SSD). En ook een Atom is niet al te snel, dus dat zou ook een beperkende factor kunnen zijn.
Zonder dollen: 108 MBps = 864 Mbps = 0.864 Gbps. Als je in gedachten houdt dat je altijd wat overhead hebt door protocol headers (minimaal 58 bytes voor iedere 1460 bytes aan data = 3.8%), dan zit je al aardig bij de maximale haalbare snelheid. Ik snap niet waar je over klaagt. Ik zou ook eerst eens kijken dan de bottleneck van je HDD (of zelfs SSD). En ook een Atom is niet al te snel, dus dat zou ook een beperkende factor kunnen zijn.
SCTP al eens een draai gegeven?
zeker niet slecht zolang ze werkelijk packetloss kunnen opvangen en niet gewoon als udp doorgaan zonder de "lost packets"
Fujitsu claimt dat tijdens tests met het versturen van bestanden tussen Japan en de VS snelheidswinsten met een factor 30 zijn behaald. Bij het gebruiken van virtuele desktops over dezelfde verbinding zou de latency slechts 1/6 bedragen ten opzichte van eerder gemeten niveaus
zal zeker een vooruitgang zijn in de gamewereld voor fps games of zelfs platform games met minder latency.. spelen op amerikaanse servers gaat dan toch eindelijk mogelijk zijn zonder 300 ping te hebben
Fujitsu claimt dat tijdens tests met het versturen van bestanden tussen Japan en de VS snelheidswinsten met een factor 30 zijn behaald. Bij het gebruiken van virtuele desktops over dezelfde verbinding zou de latency slechts 1/6 bedragen ten opzichte van eerder gemeten niveaus
zal zeker een vooruitgang zijn in de gamewereld voor fps games of zelfs platform games met minder latency.. spelen op amerikaanse servers gaat dan toch eindelijk mogelijk zijn zonder 300 ping te hebben
[Reactie gewijzigd door sp00kler op woensdag 30 januari 2013 13:50]
Games gebruiken vaak al UDP voor het snelle verkeer (beter dat je een 'stapje mist' van een speler dan dat iedereen moet wachten totdat iedereen elkaars stapje heeft). Alleen voor belangrijkere data waar latency minder belangrijk is (zoals chat of punten) wordt TCP gebruikt.
inderdaad ook veel gewoon een mix van de 2 maar een soort tcp protocol maar dan veel sneller zou zeer handig zijn ook vanwege een verloren paketje dat een "kogel" bevat wat een headshot zou moeten voorstellen... mis je ff je headshot momenteel via udp, via het nieuwe protocol zou dit niet het geval zijn, bij tcp ook niet maar tcp is veel te traag voor gaming zeker voor fps
in een echte omgeving weet ik niet of dit daadwerkelijk zo is maar denk dat men punt hier wel duidelijk is
in een echte omgeving weet ik niet of dit daadwerkelijk zo is maar denk dat men punt hier wel duidelijk is
Die headshots missen dan niet, dit zijn die situaties waarin je niks zag gebeuren maar wel ineens dood neervalt 
De gamemechanics houden echt wel betrouwbaar bij wat er allemaal rondvliegt, er wordt alleen geen moeite gedaan om de visuele updates betrouwbaar te maken aangezien latency belangrijker is dan een dropped frame ofzo (ik weet de exacte mechanics niet).
En bovendien, hoe vaak maak je tegenwoordig packetloss mee als je op een server binnen west europa speelt?
De gamemechanics houden echt wel betrouwbaar bij wat er allemaal rondvliegt, er wordt alleen geen moeite gedaan om de visuele updates betrouwbaar te maken aangezien latency belangrijker is dan een dropped frame ofzo (ik weet de exacte mechanics niet).
En bovendien, hoe vaak maak je tegenwoordig packetloss mee als je op een server binnen west europa speelt?
Iedere dag als je een Telfort-klant bent...En bovendien, hoe vaak maak je tegenwoordig packetloss mee als je op een server binnen west europa speelt?
Om precies te zijn gebruiken veel games "reliable UDP". Het simuleert TCP's zekerheid op belangrijke packets (schoten enzo), maar gebruikt gewone packets voor dingen als lopen enzo.
Hmm, niet echt nieuws in mijn ogen. Door de control's van TCP te verplaatsen naar een hogere laag kun je inderdaad bepaalde "nadelen" van TCP oplossen, maar er wordt even voorbij gegaan aan het feit dat binnen TCP al veel te tunen valt voor specifieke scenario's. Indien je een high latency verbinding met packetloss hebt, kun je bijvoorbeeld spelen met de window sizing en hoe snel deze opschaalt. De 30x sneller stelling lijkt me gebaseerd op "sane default" van een willekeurig OS. Zeker niet geoptimaliseerd voor de specifieke situatie. Ik zeg niet dat TCp per definitie even snel kan werken als UDP, maar ik denk dat dit meer een slim geschreven marketing middel is voor een commercieel product. Overigens lijkt me in de huidige tijd een implementatie van een proprietary protocol not done.
Daarnaast zijn er al vaker dit soort ideeen uitgewerkt en geoppert. Zoals Reliable UDP bijvoorbeeld. Ook heeft een UDP header bepaalde controls niet in de header, zoals handeling van fragmentatie.
Daarnaast geeft het feit dat TCP, sessie gebaseerd is (i.t.t. connectionless UDP), tussenliggende apparaten als proxies en firewalls veel meer handvaten of iets zinnigs met het verkeer te doen.
Dit protocol zal niet spoedig de wereld gaan veroveren ;-).
Daarnaast zijn er al vaker dit soort ideeen uitgewerkt en geoppert. Zoals Reliable UDP bijvoorbeeld. Ook heeft een UDP header bepaalde controls niet in de header, zoals handeling van fragmentatie.
Daarnaast geeft het feit dat TCP, sessie gebaseerd is (i.t.t. connectionless UDP), tussenliggende apparaten als proxies en firewalls veel meer handvaten of iets zinnigs met het verkeer te doen.
Dit protocol zal niet spoedig de wereld gaan veroveren ;-).
[Reactie gewijzigd door Dennizz op woensdag 30 januari 2013 13:53]
Inderdaad. Technieken als Cisco WAAS en Riverbed Steelhead doen dit al jaren.
Het protocol van Fujitsu doet alleen TCP optimalisatie. (Aangezien het daar een vervanger voor is.)
Het is geen synchrone cache, het doet geen compressie van data en het doet geen deduplicatie van data. En voor echt hoge latency links kan je het Space Communications Protocol gebruiken.
Het protocol van Fujitsu doet alleen TCP optimalisatie. (Aangezien het daar een vervanger voor is.)
Het is geen synchrone cache, het doet geen compressie van data en het doet geen deduplicatie van data. En voor echt hoge latency links kan je het Space Communications Protocol gebruiken.
Ik zie het grote voordeel nog niet erg, maar misschien heeft iemand wat meer inzicht.
Ik zie een de volgende meestgebruikte scenario's
- je wilt gamen o.i.d. : hier heb je dan een lage latency nodig met bij voorkeur weinig packet loss. De packet loss kan je niet verhelpen. Over het algemeen gaat je game client gewoon door als er packet loss is en corrigeert met de informatie uit de volgende packets die wel aankomen. Er worden dus geen packets herzonden, dus heeft dat protocol hier niet veel nut.
- je wilt video streamen : Hier maakt de latency niet uit. Tuurlijk, het is vervelend als je het doelpunt bij de buren een seconde eerder hoort maar hele volksstammen leven daar al mee. Wat packet loss maakt over het algemeen ook niet veel uit in een video stream. Overigens worden video streams gebufferd.
- je wilt (grote) files transferren: Dit gebeurt met TCP omdat je geen last van lost packets wilt hebben. Latency maakt niet uit en op een grote file maakt een seconde langer ook niet uit.
Fujitsu heeft een protocol gemaakt dat zo snel en low-latency is als UDP en zeker als TCP (claimen ze, in simulaties). Ik zie alleen de use-case niet. Je hebt genoeg aan de huidige keuze.
Mis ik iets?
Verder blijft Engels moeilijk voor Japanners (latancy)
Ik zie een de volgende meestgebruikte scenario's
- je wilt gamen o.i.d. : hier heb je dan een lage latency nodig met bij voorkeur weinig packet loss. De packet loss kan je niet verhelpen. Over het algemeen gaat je game client gewoon door als er packet loss is en corrigeert met de informatie uit de volgende packets die wel aankomen. Er worden dus geen packets herzonden, dus heeft dat protocol hier niet veel nut.
- je wilt video streamen : Hier maakt de latency niet uit. Tuurlijk, het is vervelend als je het doelpunt bij de buren een seconde eerder hoort maar hele volksstammen leven daar al mee. Wat packet loss maakt over het algemeen ook niet veel uit in een video stream. Overigens worden video streams gebufferd.
- je wilt (grote) files transferren: Dit gebeurt met TCP omdat je geen last van lost packets wilt hebben. Latency maakt niet uit en op een grote file maakt een seconde langer ook niet uit.
Fujitsu heeft een protocol gemaakt dat zo snel en low-latency is als UDP en zeker als TCP (claimen ze, in simulaties). Ik zie alleen de use-case niet. Je hebt genoeg aan de huidige keuze.
Mis ik iets?
Verder blijft Engels moeilijk voor Japanners (latancy)
[Reactie gewijzigd door Durandal op woensdag 30 januari 2013 13:58]
Viel me ook al op ja... dacht wat is dat nu weer (latancy ipv latency)
1x fout en 1x goed...
(latancy ipv latency)1x fout en 1x goed...
[Reactie gewijzigd door hawkeye73 op woensdag 30 januari 2013 14:11]
Dit protocol vangt wel packet loss op, het doet het alleen efficiënter. En kennelijk doet het ook aan slimme QOS:
(bron)1) A new protocol that incorporates an efficient proprietarily developed retransmission method based on user datagram protocol (UDP)(2), an optimized way to deliver streaming media able to reduce latency resulting from data retransmission when packet loss occurs; 2) Control technology that addresses the problem of UDP transmissions consuming excess bandwidth by performing a real-time measurement of available network bandwidth and securing an optimal amount of communications bandwidth without overwhelming TCP's share of the bandwidth; and 3) Technology that, by employing the new protocol, makes it possible to easily speed up existing TCP applications without having to modify them.
Waarbij je je meteen af kan vragen waarom je dan niet gewoon binnen de parameters van TCP een en ander zou gaan tweaken. En als er dan nog dingen beter moeten kan je als je wilt nog naar QoS kijken, hoewel de meest effectieve oplossing daarbij nog steeds is: meer bandbreedte ertegenaan gooien.
Dit verhaal levert een leuk stukje octrooi op voor Fujitsu, een leuke bonus voor de medewerkers die het verzonnen hebben en wellicht een paar rechtzaken als ze gaan vinden dat iemand straks inbreuk pleegt op hun idee.
En verder draait het Internet gewoon verder op UDP en TCP.
Dit verhaal levert een leuk stukje octrooi op voor Fujitsu, een leuke bonus voor de medewerkers die het verzonnen hebben en wellicht een paar rechtzaken als ze gaan vinden dat iemand straks inbreuk pleegt op hun idee.
En verder draait het Internet gewoon verder op UDP en TCP.
Je denkt als een thuisgebruiker. Fujitsu maakt geen producten voor Henk en zijn gezinnetje thuis! Gamen en video streamen zal daarom niet bij de doelsystemen horen voor Fujitsu.
Waar je aan moet denken zijn productiesystemen, databases etc. die real-time werken en afhankelijk zijn van een snelle en 100% complete overdracht van gegevens. Vertraging in de systemen kan productie vertragen en dat loopt bij bedrijven al snel op tot grote bedragen. Een seconde is geen ramp maar een seconde vertraging per transactie kost bedrijven enorm veel geld.
Waar je aan moet denken zijn productiesystemen, databases etc. die real-time werken en afhankelijk zijn van een snelle en 100% complete overdracht van gegevens. Vertraging in de systemen kan productie vertragen en dat loopt bij bedrijven al snel op tot grote bedragen. Een seconde is geen ramp maar een seconde vertraging per transactie kost bedrijven enorm veel geld.
Dat zijn typisch transacties op korte afstanden in betrouwbare omgevingen met dikke links. Daar is dit protocol dus niet op van toepassing aangezien ze het in de test juist hebben over een langeafstandsverbinding over brakke links (gezien de hoeveelheid latency die ze zonder dit wonderprotocol hadden).
Dat is niet meer zo. Veel bedrijven (de meesten zelfs die ik van binnen heb gezien) hebben hun datacenters outsourced. En zelfs al hebben ze hun eigen centers, dan hebben ze doorgaans nog een uitwijkcenter op behoorlijke afstand. Internationale bedrijven centraliseren naar enkele datacenters voor een groot aantal landen. Als dit het mogelijk maakt met minder datacenters te werken zou het veel geld besparen.
Dan nog ligt er tussen die datacentres echt een pad dat zo goed is dat je je kan afvragen of dit soort technologie kan helpen. Ze hebben het in het voorbeeld over een pad met drie hele seconden delay, dat is erg veel. Bovendien is bij een DC voor uitwijk de betrouwbaarheid stukker belangrijker dan de latency, dan ga je niet zitten prutsen met een of andere optimalisatie in je applicatielaag.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Asus Samsung Mobiele telefoons Laptops Apple Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
