22 replies to this topic

[40H3X]

Voor een interne share gebruik ik cs357x (UDP) met OSCam. Ik begrijp dat er een verschil is met cs378x (TCP). TCP controleert of de segmenten aan komen en of ze in de juiste volgorde staan, maar wat is de relevantie ervan in een intern netwerk?

 

Ik lees dat het cs357x protocol er eerder was en dat voor UDP werd gekozen i.v.m. de bandbreedte t.o.v. TCP.

 

(Mijn boxen zitten ook in alle in hetzelfde subnet, dus er hoeven ook geen poorten open te worden gezet).

[Jan Gruuthuse]

LAN:

- UDP is fractie sneller.

- TCP voor STB's die alleen werken met handshake (verbinding valt weg en herstelt niet meer)

[Jan Gruuthuse]

UDP laat fout controle vallen, vraagt packet niet opnieuw aan: weg is weg

[MiLo]

USP versus TCP for dummies: Don't use UDP.

Da's de razendsnelle selectie gids. Er zijn eigenlijk geen redenen om UDP te kiezen. TCP is net zo "snel" (zelfde latency), en de protocol overhead gaat nergens over.

[Erik Slagter]

UDP is alleen interessant als je wild broadcasten of als je een ontzettend "domme" (als in: 1k RAM) appliance hebt die niks kan bufferen. Anders gewoon niet gebruiken. Oh ja, bij NFS kan het sóms wat uitmaken, maar dat is weer een heel ander verhaal, meestal werkt TCP het best.

[40H3X]

Heldere standpunten dank, stap ik over naar t cs378x (TCP). Niet om door te zeuren, maar mis ik de technische onderbouwing, of is het antwoord dan beter pakket controle dan geen?

Edited by 40H3X, 10 September 2015 - 14:32.

[MiLo]

Dingen die de meeste mensen niet over UDP weten:

- UDP is een protocol naast TCP, TCP is dus niet gebaseerd op UDP (het zijn broers, geen vader en zoon, pappa heet "IP").
- TCP kan grotendeels in hardware worden afgehandeld, UDP doorgaans niet.
- Als buffers 'vol' beginnen te raken zullen de meeste netwerksystemen (te beginnen met het device zelf) alle UDP pakketten weggooien. Dus niet alleen de pakketten die er niet meer in pasten, echt alle UDP pakketten die er nog in zitten worden zondermeer weggegooid. (TCP pakketten worden doorgaans niet weggegooid. Dat heeft namelijk geen zin voor het apparaat, TCP pakketten die je weggooit komen namelijk altijd weer terug.)
- Het schrijven van een TCP achtig protocol bovenop UDP leidt tot meer overhead dan TCP al had, omdat je een aantal dingen (zoals sequencing) dubbel gaat moeten doen.

Edited by MiLo, 10 September 2015 - 14:53.

[40H3X]

Dank voor de aanvulling!

[Erik Slagter]

Voor zover je geen TCP afhandeling in hardware hebt, is het tegenwoordig, in vergelijking met de processor-power die je hebt, zodanig "light" dat dat totaal geen issue is. Zo gebruikt IP (en ook TCP en UDP) geen "zware" CRC's maar simpele checksums, alleen het ethernet frame heeft een CRC en die wordt sowieso altijd in hardware berekend. Het meeste werk is het heen-en-weer schuiven van de data binnen de kernel en naar de kaart, maar dat heb je met UDP net zo hard als met TCP. Veel NIC's op de PC kunnen dat zo goed als helemaal zelf, maar juist de NIC's in STBen zijn op dit punt ontzettend dom en vereisen dat dat allemaal door de processor gedaan wordt.

 

De reden dat veel mensen denken dat TCP bovenop UDP is geimplementeerd, is, omdat de IP-protocolstack vaak aangeduid wordt (al zolang als ik me kan herinneren) als TCP/IP. En dat slaat natuurlijk nergens op. Maarrr... UDP is wel een echt minimaal laagje op IP, het scheelt maar een paar bytes.

 

Voor TCP heb je vooral wat geheugen nodig voor het unacknowledged transmission window. Als je dat hebt, stelt het niks voor. Als je dat niet hebt, is het lastig. Ik heb zowel TCP als UDP op een Atmel ATmega328p gemaakt, die heeft 2 kilobyte geheugen en dat is nog niet eens genoeg (naast ander gebruik) voor een compleet ethernet frame. UDP kun je daar redelijk goed op maken, TCP gaat ook goed zolang je maar geen retransmissions nodig hebt

Wat ik wil zeggen is dat een microcontroller die op 8 Mhz draait geen problemen heeft met zowel UDP als TCP. Het is puur een beetje geheugen, iets van 16 k, wat je nodig hebt om een paar segments te kunnen bufferen. Als je dat hebt, maakt UDP en TCP nauwelijks meer uit qua performance, zelfs op 8 Mhz.

 

De UCB (niet de minste in dit opzicht) heeft het jaaaaaren geleden al eens uitgebreid getest en ze konden echt geen significant verschil ontdekken in performance of throughput. Sindsdien wordt aangeraden om gewoon altijd TCP te gebruiken.

[MiLo]

De winst van TCP checksum offloading zit ook niet zozeer in de berekening, maar in het moeten verzamelen en herindelen in hapklare ethernet frames.

Bij hardware offload worden de headers en data gescheiden verzameld, en pas op het laatst, als ze naar de hardware gaan, plakt deze de headers erbij en vult de checksum in. Grote voordeel is dat de CPU niet alle data moet kopieren in pakketbuffers, maar dat de datastroom gewoon aaneengesloten in geheugen kan blijven staan tot de DMA ze oppikt.

Als deze accelleratie ontbreekt, is het enige dat overblijft het vergroten van de pakketten. Dat vereist dan wel ook weer hardware support. Op een 400MHz ARM systeem zorgde het vergroten van de ethernet frames van 1.5k naar 4k voor een factor 4 meer doorvoer.

[Erik Slagter]

Rond-verplaatsen van de data zoals ik al noemde. En daar zijn de Broadcoms héél slecht in, geen scatter-gather dus alles fijn met de processor heen en weer slepen. Als die scatter-gather eens geimplementeerd zou worden, dat wel heel fijn zijn. Ook veel minder kans op geheugenfragmentatie dus meer stabiliteit.

[HPPli]

Dank alle heren voor de uitvoerige toelichting over UDP en TCP protocollen !

 

Toch wil ik de TS eens adviseren om SCAM (ook UDP) eens te proberen/testen als internal softcam share-protocol binnen Oscam.

Je zult bemerken een verrassend snelle respons (zapsnelheid) en eenvoudige/enkele regels benodigd voor de [reader] 

[40H3X]

Dank voor het advies, kun je iets meer toelichting geven m.b.t. je keuze van SCAM?

 

De reden dat ik van CCcam naar OSCam ben gegaan is het gebrek aan onderhoud m.b.t. CCcam en in mindere mate het "open soure" zijn, al is er IMHO een duidelijk casuaal verband tussen beide Ook is de Webinterface van OSCam eenvoudig ingericht, waardoor een interne share met een paar muisklikken (username/wachtwoord, protocol keuze en poort en een reader op de client) zo was opgezet.

 

Tevens begrijp ik niet helemaal, waarom er in http://forums.openpl...de-transponder/ is gekozen voor een CCcam reader. Ik heb het idee dat de protocollen cs378x en cs357x native zijn voor OSCam en het lijkt me (op niks gebaseerd overigens) niet logisch een obsolete CCcam als reader te gebruiken, hoe zit dat met SCAM?

[HPPli]

Scam is de meest recht toe aan verbinding tussen een (scam)server en een oscamclient. M.a.w. scam werkt enkel als een simpele ECM-Server.

Let wel, een scam-server kan niet (terug) antwoorden als er na een ECM-aanvraag geen goede CW wordt gevonden na een ECM aanvraag.

 

Ik ben ook om dezelfde reden veranderd van cccam naar oscam en mijn slaapkamer "kijkt" nu mee middels het scam protocol/connectie naar mijn woonkamer-STB.

 

Waarom CCcam wordt gebruikt als 1e protocol bij OpenPli is misschien een waard aan de heren Devs van OpenPli, ik heb er geen moeite mee. Het mooie aan Openpli

is wel dat de softcam Oscam het meest simpel is te installeren en direct klaar voor de gebruiker.

[Erik Slagter]

Overigens is mijn ervaring dat Oscam in vroege versies problemen had met TCP-verbindingen. Er werden vaak veel connecties tegelijk opgezet, of vlak na elkaar, onnodig, waardoor de serverkant nogal eens de toegang blokkeerde. Maar dat is inmiddels vast wel opgelost.

[40H3X]

Scam is de meest recht toe aan verbinding tussen een (scam)server en een oscamclient. M.a.w. scam werkt enkel als een simpele ECM-Server.

Let wel, een scam-server kan niet (terug) antwoorden als er na een ECM-aanvraag geen goede CW wordt gevonden na een ECM aanvraag.

 

Ik ben ook om dezelfde reden veranderd van cccam naar oscam en mijn slaapkamer "kijkt" nu mee middels het scam protocol/connectie naar mijn woonkamer-STB.

 

Waarom CCcam wordt gebruikt als 1e protocol bij OpenPli is misschien een waard aan de heren Devs van OpenPli, ik heb er geen moeite mee. Het mooie aan Openpli

is wel dat de softcam Oscam het meest simpel is te installeren en direct klaar voor de gebruiker.

 

Ik heb SCAM net getest en merk geen verschillen met het protocol cs378x, toch dank voor de tip

Edited by 40H3X, 20 September 2015 - 11:15.

[theparasol]

Als je oscam <> oscam connecteert moet je echt geen cccam share protocol meer willen gebruiken. EMM support is oa borked. Connection handling is ook niet zo fijnzinnig.

Scam heb ik geen ervaring mee maar cs378 of cs357 is idd aan te raden.

[40H3X]

Die gebruik ik ook niet (ik gebruik OSCam <> OSCam intern share met het cs378x protocol. Ik vond het dan ook opmerkelijk dat er nu standaard in de (overigens prima voor geconfigureerde OSCam vlgns mij door Tech) oscam.server file een CCcam reader is toegevoegd?

[40H3X]

(edit).....terwijl ik zou zeggen weg met die CCcam meuk

[theparasol]

old habits die hard...