ESP8266 Community Forum

- Sun Oct 25, 2020 8:49 am #89209 In that case my findings of ~450 bkps for UDP and ~320 kbps for TCP aren't that bad an indicator I think. I must say I have disabled a few optimisations in LWIP as to reduce memory usage. So for instance I disabled fragmentation/reassembly and I minimised the TCP window size, so any dropped frame will result in a slow-start. TCP transmission control isn't actually really needed on WLAN because 802.11 already implements it on layer 2, it's very seldom that you don't get a frame delivered or out of sequence. If that happens, the connection is already very bad. My experience is that UDP works indeed very well on WLAN, unless it's multicast, which gets very low (QoS) priority.

BTW I do zero-copy, I can imagine not every application is suitable for that. It appears that the SDK copies the frames to it's own memory anyway, so it's best to not duplicate that action.

- Sun Oct 25, 2020 9:28 am #89210

For mass production you can preload the flash before putting it on the board, if that's the only thing you're worried about. There are many companies that will sell modules in bulk with the flash already loaded with whatever image you give them - this is what they do with NodeMCU units.

If you're doing smaller batches then the other thing to consider of course is that with UART flashing, you can flash maybe 12-16 units at a time max (I do 8 at a time), whereas OTA you'll be able to do over a hundred at a time if you have the power supplies for them.

But if I were mass producing then I would just get the flash pre-loaded - very simple

First, very often, bosses don't expect to release image outside, even though esp8266 does not protect flash image.

Secondly, some parameters specific to this hardware have to be flashed online of whole module such as RF calibration, serial number if any etc. -- sure, it is feasible to burn most of the flash image and only burn those data specific to module one by one.

- Sun Oct 25, 2020 9:36 am #89211 /quote]
I mean your wifi rate in general - I have a side project that will need to stream data and I want to know how fast I can get it in steady state[/quote]

Not quite sure about your concern. Are you concerned about the speed of an OTA or just the throughput of an 8266 module? If latter, the effective throughput could exceed 1Mbytes per seconds. In China there is such a stable and fast esp8266 module using SPI as the host interface in mass production. If you feel interested, contact with me.

- Sun Oct 25, 2020 10:54 am #89213 Davy Norris is quite knowledgeable on the subject.

I've seen other claims of such high throughputs, but I am sceptical. To begin with it probably counts the whole frames, including L2 and L3 metadata (which is considerable with IP and 802.11). Furthermore they probably count in bits per second, which I honestly find quite senseless, because I am working with bytes, not bits. 426 kBYTES/s = 3.4 megaBITS/s.

From my OTA benchmark (and as you can see everything is in kiloBYTES per second). I've know to achieve higher rates, there is probably some noise/interference going on at the moment.

espflash -u -h esp1 -f test --length 390352 --start 0x002000 -R
flash operations available, sector size: 4096, OTA update available, slots: 2, current slot: 0, address[0]: 0x002000, address[1]: 0x102000, address[2]: 0x000000, address[3]: 0x000000, preferred chunk size: 4096
start read from 8192, length: 390352, flash buffer size: 4096, chunk size: 4096
received 380 kbytes in 1.02 seconds at rate 374 kbytes/s, received 96 sectors, 99%
checksumming 96 sectors...
checksumming done
espflash -t -h esp1 -f test --length 390352 --start 0x002000 -R
flash operations available, sector size: 4096, OTA update available, slots: 2, current slot: 0, address[0]: 0x002000, address[1]: 0x102000, address[2]: 0x000000, address[3]: 0x000000, preferred chunk size: 4096
start read from 8192, length: 390352, flash buffer size: 4096, chunk size: 4096
received 380 kbytes in 1.31 seconds at rate 290 kbytes/s, received 96 sectors, 99%
checksumming 96 sectors...
checksumming done
espflash -u -h esp1 -f espiobridge-rboot-image.bin -S
flash operations available, sector size: 4096, OTA update available, slots: 2, current slot: 0, address[0]: 0x002000, address[1]: 0x102000, address[2]: 0x000000, address[3]: 0x000000, preferred chunk size: 4096
start simulate, at address: 0x002000, length: 440464, flash buffer size: 4096, chunk size: 4096
sent 430 kbytes in 1.01 seconds at rate 426 kbytes/s, sent 108 sectors, written 0 sectors, erased 0 sectors, skipped 108 sectors, 100%
simulate finished
espflash -t -h esp1 -f espiobridge-rboot-image.bin -S
flash operations available, sector size: 4096, OTA update available, slots: 2, current slot: 0, address[0]: 0x002000, address[1]: 0x102000, address[2]: 0x000000, address[3]: 0x000000, preferred chunk size: 4096
start simulate, at address: 0x002000, length: 440464, flash buffer size: 4096, chunk size: 4096
sent 430 kbytes in 1.49 seconds at rate 288 kbytes/s, sent 108 sectors, written 0 sectors, erased 0 sectors, skipped 108 sectors, 100%
simulate finished