Some socket reads use SOCK_MAX_TIMEOUT and other uses SOCK_TIMEOUT

[dave2]

I was trying to figure out why it seemed like packets were being queued in the esp8266 wifi layer, and found that in the various RX paths there are different timeouts passed. By default, SOCK_MAX_TIMEOUT is const(5), while SOCK_TIMEOUT is 0.05. Consequently, some but not all reads are affected by a 50ms timeout rather than a 5 second one.

The right fix seems to be to remove one of them and use one value, unless there's a good reason to sometimes only wait 50ms for a response from the server?

[dave2]

Actually, now that I think about it, I assume it's to ensure the read doesn't stall other parts of the main loop, but this doesn't seem to be reading packets often enough on my hardware.

It feels like it needs (u)asyncio for a read/timer loop instead, plus it could then coexist with other tasks.

[antohaUa]

Hi dave2, I think before all you can try to play with library TIMEOUT values. Each 0.05 sec library tries to read smth from device. If read speed should be increased - you need to decrease timeout value ( try 0.02 for example). SOCK_MAX_TIMEOUT value used only for authentification and set_heartbeat calls - but you also can try to play with it if you see stucks.

About asyncio Unfortunately usayncio not supported by native micropython package - thus for end users it can be really difficult to install it and use. But anyway I thing it is good idea for future to create asyncio library version additionally in parallel.

Inform me please about your test results ( I mean TIMEOUTs hardcoded values change according your HW needs)

[antohaUa]

Can be closed