TCP performance: recv/send buffers memory mappen

Pagina: 1
Acties:

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Ik ben bezig met een kleine server voor een game (RA2) en ik vroeg me af of het mogelijk is de TCP buffers te memory mappen zodat data niet meer onnodig gekopieerd hoeft te worden tussen kernel- en user-space.
Is dit mogelijk en zo ja, onder welke OSs?

Performance problemen met mijn server heb ik niet, maar ik wil dit graag weten.

  • PommeFritz
  • Registratie: Augustus 2001
  • Laatst online: 10-07 04:13

PommeFritz

...geen friet

Linux kan het met de sendfile() system call. *BSD ook geloof ik. Voor Windows weet ik het niet.

FireFox - neem het web in eigen hand


  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Ik verstuur alleen geen files, dus sendfile is niet bruikbaar.

  • madwizard
  • Registratie: Juli 2002
  • Laatst online: 26-10-2024

madwizard

Missionary to the word of ska

In windows kun je WSASend/WSARecv gebruiken, daar kan je je eigen buffers opgeven. TransmitPackets is ook efficient geloof ik, maar is XP+ only.

www.madwizard.org


  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
madwizard schreef op 04 juni 2003 @ 23:48:
In windows kun je WSASend/WSARecv gebruiken, daar kan je je eigen buffers opgeven. TransmitPackets is ook efficient geloof ik, maar is XP+ only.
Ja, maar dat kan met standaard send/recv ook. De onnodige copy is juist die van user-buffer naar kernel-buffer die dan nodig is.
TransmitPackets is niet bruikbaar omdat ik geen files verstuur.

  • madwizard
  • Registratie: Juli 2002
  • Laatst online: 26-10-2024

madwizard

Missionary to the word of ska

OlafvdSpek schreef op 04 June 2003 @ 23:58:
Ja, maar dat kan met standaard send/recv ook. De onnodige copy is juist die van user-buffer naar kernel-buffer die dan nodig is.
Ik weet niet of WSARecv/WSASend nog kopieert, maar er is wel 1 verschil met de gewone send en recv, namelijk dat bij WSA* je buffers geldig moeten blijven zolang als de operatie duurt. Bij blocking sockets maakt dat allemaal niet uit natuurlijk en ik geloof dat ze bij non-overlapped, non-blocking sockets ook nog de buffers kopieren, maar bij overlapped denk ik dat ze direct uit de buffers lezen.

edit: Ik denk dat zoiets ook alleen maar kan bij overlapped sockets, omdat je bij non-overlapped nooit weet wanneer de operatie voltooid is...
TransmitPackets is niet bruikbaar omdat ik geen files verstuur.
Dat maakt niet uit, TransmitFile is voor files, TransmitPackets voor alles.

[ Voor 11% gewijzigd door madwizard op 05-06-2003 00:09 ]

www.madwizard.org


  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Dat lijkt al een beetje op wat ik zocht, maar overlapping IO is net weer wat lastiger te programmeren dan non-blocking IO.

Ook heeft directe buffertoegang nog een aantal andere voordelen. De app hoeft bijvoorbeeld niet onnodig recv buffers gereed te houden, wat bij veel connecties geheugen scheelt.

Ik ga toch eens uitzoeken hoe het met Linux zit en kijken of dit desnoods niet toegevoegd kan worden.

  • MisterData
  • Registratie: September 2001
  • Laatst online: 19:41
Wat je probeert te doen is een beetje DirectDraw-idee maar dan voor TCP/IP?

Volgens mij bestaat dat niet onder Windows, of je moet er zelf een driver voor schrijven.

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Ja, inderdaad. En blijkbaar bestaat het zelfs onder Linux niet.

  • madwizard
  • Registratie: Juli 2002
  • Laatst online: 26-10-2024

madwizard

Missionary to the word of ska

Als je zulke performance nodig hebt dat memory copies problemen gaan geven is overlapped I/O zowieso wel aan te raden. Vooral met een I/O completion port kun je met gemak tienduizenden verbindingen aan.
Een interessant artikel over de performance van winsock:
Network Programming for Windows: Chapter 6: Scalable Winsock Applications continued

En nog een, staan ook wat dingen in over buffering en andere optimalisaties:
Windows Sockets 2.0: Write Scalable Winsock Apps Using Completion Ports

www.madwizard.org


  • PommeFritz
  • Registratie: Augustus 2001
  • Laatst online: 10-07 04:13

PommeFritz

...geen friet

Ik weet niet of je hier wat aan hebt, maar er is bijvoorbeeld een zero-copy kernel mode HTTP accelerator voor Linux, genaamd TUX Dus volgens mij kan het wel, moet je even kijken hoe Tux dat gedaan heeft.

FireFox - neem het web in eigen hand


Verwijderd

OlafvdSpek schreef op 05 June 2003 @ 21:13:
Ja, inderdaad. En blijkbaar bestaat het zelfs onder Linux niet.
Uhm, memory mappen gaat in Linux gewoon via de POSIX call mmap()...

(Of snap ik je vraag gewoon niet?)

[ Voor 46% gewijzigd door Verwijderd op 07-06-2003 15:23 ]


  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Verwijderd schreef op 07 June 2003 @ 15:22:
Uhm, memory mappen gaat in Linux gewoon via de POSIX call mmap()...

(Of snap ik je vraag gewoon niet?)
Daarmee kun je files mappen, maar geen TCP buffers, toch?
PommeFritz schreef op 07 June 2003 @ 14:36:
Ik weet niet of je hier wat aan hebt, maar er is bijvoorbeeld een zero-copy kernel mode HTTP accelerator voor Linux, genaamd TUX Dus volgens mij kan het wel, moet je even kijken hoe Tux dat gedaan heeft.
Ik wil in user-mode code inderdaad ongeveer hetzelfde doen als TUX met zero-copying.

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
madwizard schreef op 06 June 2003 @ 18:19:
Als je zulke performance nodig hebt dat memory copies problemen gaan geven is overlapped I/O zowieso wel aan te raden. Vooral met een I/O completion port kun je met gemak tienduizenden verbindingen aan.
Een interessant artikel over de performance van winsock:
Network Programming for Windows: Chapter 6: Scalable Winsock Applications continued
Zeer interessant. Volgens mij kunnen de meeste problemen die in Resource
Management beschreven staan worden opgelost met memory mapped buffers.

De app hoeft geen zero-byte receive buffers te posten.
De app hoeft geen rekening te houden met de page size.
De kernal hoeft geen overlapped IO request packets bij te houden.[/quote]

[ Voor 60% gewijzigd door Olaf van der Spek op 08-06-2003 19:08 ]

Pagina: 1