Early Design Thoughts » History » Version 2
laforge, 05/12/2018 10:16 AM
socket buffer testing
1 | 1 | laforge | h1. osmo-e1d |
---|---|---|---|
2 | |||
3 | The envisioned osmo-e1d is a daemon that handles Osmocom E1 interfaces. Its main tasks are: |
||
4 | |||
5 | # communicate with each E1 line hardware interface via USB [[USB_Protocol]] (or UDP/IP) |
||
6 | # provide a per-timeslot interface towards the users (such as [[OsmoBSC:]] and [[OsmoMGW:]] |
||
7 | #* likely unix domain socket based, so [[libosmo-abis:]] and friends can keep their "one FD per |
||
8 | # provide some kind of interface by which the user application can |
||
9 | #* perform line/interface based operations |
||
10 | #** enumerate the list of available interfaces/lines |
||
11 | #** obtain status information (LOS, Alarm, CRC4 errors, etc) on each line |
||
12 | #* timeslot based |
||
13 | #** claim/release individual timeslots |
||
14 | #** enable/disable Rx/Tx of individual timeslots (could be implicit in claim?) |
||
15 | #** switch individual timeslots between raw and HDLC/CRC mode |
||
16 | #** obtain timeslot status information such as CRC16 errors, frame errors, ... |
||
17 | # implement any internal handling required, such as |
||
18 | #* perform tasks not implemented by the adapter hardware/firmware (CRC4 tx / rx, multiframe alignment, LOS / ALRM / state machines) |
||
19 | #* implement HDLC on each requested timeslot |
||
20 | |||
21 | h2. User point of view |
||
22 | |||
23 | A user application would be interested in performing the following operations: |
||
24 | |||
25 | * obtain a list of lines/interfaces |
||
26 | * obtain a list of timeslots at a given line/interface, including availability status |
||
27 | * select/open a given timeslot on a given line |
||
28 | * enable/disable a given timeslot |
||
29 | * switch mode (raw/hdlc) of a given timeslot |
||
30 | * obtain line status information like local/remote CRC4 / LOS / ALARM |
||
31 | * receive data from a given TS |
||
32 | * transmit data on a given TS |
||
33 | 2 | laforge | |
34 | h3. Flow Control |
||
35 | |||
36 | Ideally we'd want to make the writer to a timeslot-fd block until more data can be sent via the E1 device. In DAHDI/mISDN, that's easy as their drivers are part of the kernel which can mark file descriptors/sockets as write-able at arbitrary times. |
||
37 | |||
38 | If we're using sockets or pipes between the application and osmo-e1-daemon, we have to see what kind of buffering those mechanisms have built-in. running a small (attached) test program renders: |
||
39 | <pre> |
||
40 | socketpair: tx_buf 1: written 4480 of 1048576 |
||
41 | socketpair: tx_buf 2: written 4480 of 1048576 |
||
42 | socketpair: tx_buf 4: written 4480 of 1048576 |
||
43 | socketpair: tx_buf 8: written 4480 of 1048576 |
||
44 | socketpair: tx_buf 16: written 4480 of 1048576 |
||
45 | socketpair: tx_buf 32: written 4480 of 1048576 |
||
46 | socketpair: tx_buf 64: written 4480 of 1048576 |
||
47 | socketpair: tx_buf 128: written 4480 of 1048576 |
||
48 | socketpair: tx_buf 256: written 4480 of 1048576 |
||
49 | socketpair: tx_buf 512: written 4480 of 1048576 |
||
50 | socketpair: tx_buf 1024: written 4480 of 1048576 |
||
51 | socketpair: tx_buf 2048: written 4480 of 1048576 |
||
52 | socketpair: tx_buf 4096: written 8064 of 1048576 |
||
53 | socketpair: tx_buf 8192: written 16256 of 1048576 |
||
54 | socketpair: tx_buf 16384: written 32640 of 1048576 |
||
55 | socketpair: tx_buf 32768: written 65408 of 1048576 |
||
56 | socketpair: tx_buf 65536: written 146176 of 1048576 |
||
57 | socketpair: tx_buf 131072: written 292352 of 1048576 |
||
58 | socketpair: tx_buf 262144: written 548160 of 1048576 |
||
59 | socketpair: tx_buf 524288: written 1048576 of 1048576 |
||
60 | pipe: tx_buf 0: written 65536 of 1048576 |
||
61 | </pre> |
||
62 | |||
63 | so on an x86_64 system with a 4.15 kernel, the minimum transmit buffer is 4480 bytes. so we will have up to 4480 bytes (equalling 560 milliseconds at a 64kBps E1 timeslot) in the transmit buffer of the application side, before it starts to block writes. This is unfortunately not very useful, as half a second of buffering in audio telephony is not acceptable. That's more than a geostationary satellite :/ |