‘Solana-data is traag of onvolledig?’ Wat je in je ontvangstinfrastructuur moet controleren
Je neemt een snelle Solana Shreds-stream af, maar er komen nauwelijks pakketten binnen. De Shreds die je ontvangt zijn correct te ontleden, maar er ontbreken te veel fragmenten om transacties uit te lezen. gRPC werkt wel op dezelfde server, waardoor je niet weet waar je verder moet zoeken.
Controleer naast de verzender ook je applicatieserver en het datacenter waarin die staat. Zelfs wanneer ERPC Shreds snel doorstuurt, kunnen UDP-beperkingen op het netwerkpad of verwerkingsknelpunten op de ontvangende server ervoor zorgen dat je applicatie die snelheid niet kan benutten.
Bij het kiezen van een Shreds-stream telt het hele traject: hoe de pakketten aankomen en hoe ze bruikbare data worden. Netwerkkwaliteit, afstand en het operationele beleid van het datacenter zijn ook bepalend voor de prestaties van Geyser Yellowstone gRPC, regulier RPC- en API-verkeer en het indienen van transacties.
Verzendregistraties en bruikbare ontvangen data zijn verschillende waarnemingen
Bij een recente supportvraag aan ERPC registreerden korte metingen aan de verzendkant ongeveer 3.400–3.900 pakketten/sec. Aan de ontvangstkant werd ongeveer 13 pakketten/sec gemeld, zonder dat de reconstructie van een slot werd voltooid.
Deze cijfers komen uit verschillende meetperioden. Ook is niet bevestigd dat de meetmethoden vergelijkbaar zijn. Ze geven daarom geen afleveringspercentage of verliespercentage aan. Registraties aan de verzendkant bewijzen op zichzelf niet dat de pakketten op de bestemming aankomen. Op het moment van schrijven is de uiteindelijke oorzaak nog niet vastgesteld.
Een paar duizend PPS betekent op zichzelf evenmin dat de belasting uitzonderlijk hoog is voor een gewone server. De vragen zijn wat er op het werkelijke netwerkpad gebeurt, welke beperkingen gelden, hoe sterk verkeer zich in korte perioden concentreert, hoe de ontvangst wordt verwerkt en wat elke teller precies meet.
Allebei in Frankfurt, maar via verschillende netwerkpaden
De bron van je stream en je applicatieserver kunnen allebei in Frankfurt staan, maar zich toch in verschillende datacenters bevinden. In zo’n configuratie kan verkeer het ene gebouw verlaten, via een extern netwerk lopen en het andere gebouw binnengaan. Dezelfde regionaam betekent niet automatisch dezelfde locatie, netwerkbeheerder of tussenliggende apparatuur.
Wanneer ERPC-streams of RPC-diensten worden gecombineerd met een ERPC VPS of Bare Metal op dezelfde locatie, staan de servers voor die diensten en de applicatieserver in racks dicht bij elkaar. Het verkeer tussen deze servers blijft op het interne netwerk. Dat is het idee achter ERPC’s Zero-Distance Communication: de fysieke plaatsing en het pad naar de ontvangende applicatie samen ontwerpen, in plaats van alleen dezelfde stad te kiezen.
Door een externe omweg tussen ERPC-diensten en de applicatieserver te vermijden, wordt het pad korter. Op dat traject neemt ook de invloed van congestie en routewijzigingen op externe netwerken af. Een kort pad, gecombineerd met voldoende middelen voor ontvangst en verwerking, vormt de basis om een snelle stream te benutten. Controleer het resultaat zowel bij de aankomst van pakketten als bij de verwerking in de applicatie.
Netwerkomstandigheden beïnvloeden alle soorten communicatie
Bij Shreds maken ontbrekende fragmenten het probleem zichtbaar, maar de kwaliteit van dezelfde infrastructuur heeft ook gevolgen voor dataontvangst, API-verzoeken en het indienen van transacties. Het protocol bepaalt welke symptomen de applicatie ziet en op welke punten meten zinvol is.
| Communicatie | Waar netwerkeffecten zichtbaar worden | Wat je in de applicatie controleert |
|---|---|---|
| Shreds / UDP | Pakketverlies en vertraging, en de aankomst van fragmenten die voor reconstructie nodig zijn | Geldige Shreds en de tijd totdat data kan worden gereconstrueerd |
| Geyser Yellowstone gRPC | Wachten op TCP-hertransmissies, opstopping en vertraging in de stream | De tijd totdat dezelfde update is ontvangen en verwerkt |
| RPC, API’s en verkeer tussen diensten | De heen- en terugweg van verzoeken en antwoorden, en wachttijd bij congestie | Antwoordtijd en de variatie daarin |
| Transacties indienen | Het pad van het verzoek naar de ontvangende node | De tijd vanaf het verzendverzoek tot het antwoord van de node |
Een nabije plaatsing en passend operationeel beleid ondersteunen al dit verkeer. Meet de antwoordtijd van de ontvangende node afzonderlijk van de tijd totdat een transactie on-chain wordt opgenomen en gefinaliseerd.
Gbps vertelt niet alles over PPS en verkeerspieken
Bandbreedte beschrijft hoeveel data in een bepaalde tijd kan worden vervoerd. PPS geeft het aantal pakketten aan dat per seconde wordt verwerkt. Een verbinding kan nog bandbreedte over hebben, maar toch een limiet op de pakketsnelheid of een beperking voor UDP bereiken. Ook de officiële documentatie van cloudproviders behandelt bandbreedte- en PPS-limieten als afzonderlijke beperkingen.[1]
Shreds komen bovendien niet noodzakelijk in een gelijkmatig tempo aan. Een korte verkeerspiek kan druk op wachtrijen veroorzaken die in een gemiddelde onzichtbaar blijft. Wanneer pakketten sneller binnenkomen dan een netwerkapparaat of ontvanger ze kan verwerken, kunnen pakketten boven de capaciteit van de wachtrij worden weggegooid.[2]
Vraag je hostingprovider naar aanhoudend UDP-verkeer, korte pieken, PPS-limieten en de regels van DDoS-bescherming. Het doel is vast te stellen onder welke voorwaarden het benodigde verkeer veilig kan worden toegelaten, zonder beveiligingsmaatregelen zomaar uit te schakelen.
Werkend gRPC bewijst niet dat UDP goed wordt ontvangen
gRPC op basis van TCP en de overdracht van onbewerkte Shreds via UDP gebruiken verschillende transportmechanismen. TCP verzorgt hertransmissie en volgorde. Streaming via gRPC heeft flowcontrol die rekening houdt met de capaciteit van de ontvanger. UDP zelf verstuurt ontbrekende pakketten niet opnieuw en laat de verzender niet wachten totdat de ontvangende applicatie de achterstand heeft ingehaald.[3]
Dat gRPC op een server werkt, bewijst dus niet dat het UDP-pad of de UDP-ontvangst ook goed werkt. Filters per protocol, poorten, afleverroutes en de implementatie van de ontvanger moeten apart worden gecontroleerd. Verwerkingsvertragingen bij gRPC kunnen zich eveneens uiten als wachttijd of verbroken verbindingen.
Transacties/sec bij gRPC en pakketten/sec bij UDP zijn verschillende eenheden op verschillende verwerkingsniveaus. Je kunt ze niet rechtstreeks vergelijken om de hoeveelheid geleverde data of een verliespercentage te berekenen.
Van binnenkomende pakketten naar bruikbare data
Bij een gewone UDP-socketontvanger gaan binnenkomende pakketten via de NIC, de kernel en de ontvangstbuffer van de socket naar de applicatie. Als de verwerking achterloopt, kunnen pakketten ook na aankomst op de host worden weggegooid. De ontvangsttellers van Linux-netwerkinterfaces bevatten pakketten die later alsnog worden weggegooid. Een stijgende ontvangstteller alleen bewijst daarom niet dat data de applicatie heeft bereikt.[4]
Een afzonderlijke ontvangstwachtrij of CPU-core kan druk bezet zijn terwijl het totale CPU-gebruik laag is. Controleer de NIC-wachtrijen, de verdeling van interrupts en de prestaties per core. Scheid in de applicatie de ontvangst waar nodig van de verdere verwerking. Houd zware analyse en overmatige loguitvoer buiten de ontvangstlus. Een grotere ontvangstbuffer kan tijdelijke pieken opvangen, maar lost een aanhoudend tekort aan verwerkingscapaciteit niet op.[5]
Shreds zijn fragmenten van blokdata. Voorwaartse foutcorrectie (FEC) kan ontbrekende data herstellen met data Shreds en coding Shreds uit dezelfde groep. Voor reconstructie blijven echter voldoende fragmenten nodig. Meer dubbele pakketten vervangen de ontbrekende fragmenten niet.[6]
Afhankelijk van de implementatie kan een ontvanger entries reconstrueren uit beschikbare fragmenten voordat het hele slot compleet is.[9] Meet naast het totale aantal pakketten ook geldige unieke Shreds, gereconstrueerde data en de tijd totdat de applicatie de benodigde gebeurtenis herkent.
Meet elke stap binnen hetzelfde tijdvenster
Stem de bestemming, poort en het meetvenster aan beide kanten op elkaar af. Door de volgende stappen afzonderlijk vast te leggen, kun je gerichter bepalen wat je verder moet onderzoeken.
| Meetpunt | Wat je vastlegt | Wat het aantoont |
|---|---|---|
| Verzender | Registraties voor de bedoelde bestemming en de definitie van de teller | Welke stap van de verzending is waargenomen |
| Ingang van de ontvangende host | Capture van het bedoelde UDP-verkeer, NIC-statistieken en gemiste pakketten in de capture zelf | Hoeveel verkeer op dat waarnemingspunt zichtbaar was |
| Besturingssysteem en socket | UDP-fouten, drops in de ontvangstbuffer en veranderingen in wachtrijen | Of de ontvangstverwerking binnen de host achteropraakt |
| Reconstructie van Shreds | Geldige unieke Shreds, geslaagde reconstructies, ontbrekende data en fouten | Of de pakketten de benodigde data opleveren |
| Applicatie | Verwerkingsachterstand en detectietijdstippen van dezelfde gebeurtenis | Of de snelle aankomst daadwerkelijk in de applicatie wordt benut |
Als een capture weinig pakketten laat zien, controleer dan eerst het filter, de waargenomen interface, verliezen in de capture zelf en drops bij de NIC. Sommige tellers van het besturingssysteem gelden voor de hele host of netwerknamespace. Controleer hun bereik en breng ze in verband met metingen van de bedoelde applicatie.[4][5]
Pas instellingen aan nadat je hebt vastgesteld waar de beperking zit. Alleen een buffer of ring vergroten kan het knelpunt verplaatsen of de wachttijd verhogen. De actuele ERPC-configuratie voor ontvangst en de bijbehorende controles staan hier:
Kies ook het operationele beleid, niet alleen de server
De Solana Foundation legt uit waarom controle over NIC’s, fysieke cores, drivers en netwerken belangrijk is voor krachtige validators. De volledige vereisten voor een validator moeten echter niet zonder meer op elke Shreds-ontvanger worden toegepast. Een ontvangende applicatie heeft een configuratie nodig die past bij de eigen stream en verwerkingslast.[7]
Kosten of energieverbruik verlagen is een begrijpelijk bedrijfsdoel. HFT- en realtimeapplicaties hebben daarnaast een snel reagerende CPU, aanhoudende verwerkingscapaciteit en korte wachttijden op het netwerk nodig. Ontwaken uit een energiebesparende toestand kan extra latentie met zich meebrengen.[8]
Controleer naast het CPU-model en het aantal cores hoe resources worden gedeeld, hoe met langdurige belasting wordt omgegaan, welke voorwaarden gelden voor UDP-verkeer en welk netwerkpad daadwerkelijk wordt gebruikt.
ERPC bekijkt de stream en de ontvangstomgeving als één geheel
ERPC werkt aan de selectie van datacenters dicht bij Solana-infrastructuur, netwerkpaden, hardware en operationele instellingen. Naast Shreds en gRPC bieden we VPS en Bare Metal aan. Je kunt een VPS kiezen die past bij je verwerkingslast en Bare Metal vergelijken wanneer je fysieke resources exclusief wilt gebruiken.
Kennis van de configuratie en het beheer van de omgevingen die we aanbieden, helpt ook bij technische ondersteuning. We kunnen registraties aan de verzendkant vergelijken met metingen aan de ontvangstkant en concrete controles bepalen voor netwerk, besturingssysteem of applicatie. Bij de hier beschreven supportvraag hebben we de metingen aan de verzendkant gecontroleerd en om aanvullende metingen bij de ontvanger gevraagd.
Door de stream, de plaatsing van de ontvanger en de implementatie van de applicatie samen te beoordelen, wordt duidelijker wat er nog ontbreekt tussen de gekozen dienst en de data die je nodig hebt.
Vergelijk je huidige omgeving met facturering per uur
Twijfel je aan je ontvangstomgeving, probeer dan een ERPC VPS of Bare Metal met facturering per uur en vergelijk dezelfde stream en applicatie. In het dashboard vind je de actuele prijzen, beschikbaarheid en bestelvoorwaarden voor de gewenste regio.
Begin met een beschikbare configuratie en registreer ontvangstaantallen, gereconstrueerde data, verwerkingsachterstand en detectietijdstippen van dezelfde gebeurtenissen. Controleer bij het vergelijken van tijdstempels tussen hosts ook de nauwkeurigheid van de kloksynchronisatie. Herhaal de test op verschillende tijdstippen en vergelijk waar in het traject de resultaten verschillen. Gebruik die metingen om een server en datacenter te kiezen die bij je applicatie passen.
- VPS: https://erpc.global/nl/vps/
- Bare Metal: https://erpc.global/nl/baremetal/
- Dashboard: https://dashboard.erpc.global/nl/
Gerelateerde artikelen
- Solana Stream SDK v4.0.0: https://erpc.global/nl/news/2026/11/07/erpc-solana-stream-sdk-v4-20261107/
- [9] Shreds UDP Forwarding Premium: https://erpc.global/nl/news/2026/11/03/erpc-shreds-udp-forwarding-premium-20261103/
- Officiële Discord van Validators DAO: https://discord.gg/C7ZQSrCkYR
Technische bronnen
- [1] AWS EC2: bandbreedte- en PPS-limieten: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html
- [2] IETF UDP Usage Guidelines, verkeerspieken: https://www.rfc-editor.org/rfc/rfc8085.html#section-3.1.6
- [3] Linux UDP: https://man7.org/linux/man-pages/man7/udp.7.html
- [3] Linux TCP: https://man7.org/linux/man-pages/man7/tcp.7.html
- [3] gRPC-flowcontrol: https://grpc.io/docs/guides/flow-control/
- [4] Statistieken van Linux-netwerkinterfaces: https://docs.kernel.org/networking/statistics.html
- [4] libpcap: capturegedrag en gemiste pakketten: https://github.com/the-tcpdump-group/libpcap/blob/master/doc/README.linux
- [5] Schalen van de Linux-netwerkstack: https://docs.kernel.org/networking/scaling.html
- [5] Ontvangstbuffers van Linux-sockets: https://man7.org/linux/man-pages/man7/socket.7.html
- [5] Red Hat: UDP-drops onderzoeken: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/network_troubleshooting_and_performance_tuning/tuning-udp-connections
- [6] Anza Turbine Block Propagation: https://docs.anza.xyz/consensus/turbine-block-propagation/
- [7] Solana Foundation: hardware voor krachtige validators: https://solana.com/news/high-performance-solana-validators-run-on-bare-metal-hardware
- [8] Beheer van CPU-idletoestanden in Linux: https://docs.kernel.org/admin-guide/pm/cpuidle.html
