Call mpr_dev_update_maps() once all signals have been updated.

[malloch]

This change will cause libmapper to send updates to mapped peers immediately rather than waiting for the next call to mpr_dev_poll().

[aburt2]

tested with the esp32s3, just needs resolve conflicts with the main branch before merging

[malloch]

Would be interesting to re-run the latency & throughput benchmarks once this PR and the liblo updates merged...

[aburt2]

On the branch I'm working on to add support for 5G T-Sticks I have added this PR already, under good network conditions & PC connected to ethernet to router, OSC throughput is between 104-106Hz, with round-trip latency ranging from 2ms - 13ms

[aburt2]

under poor network conditions (ie: using my phone as an access point) the round trip latency can range from 20ms to the ESP32 doesn't respond to pings once it gets that high, libmapper does not work (ESP32 is not visible) but you can still maintain a 104-106Hz throughput via OSC just a very delayed 104Hz

[malloch]

The "ESP32 not visible to libmapper" condition is 100% due to dropped packets. I have a branch where I'm integrating TCP for administrative traffic (which should resolve visibility) but the dropped packets are still very problematic. Some of the signals generated by the T-Stick (e.g. jabs) are ballistic/event-based so a single dropped packet can have bad consequences!

Out of curiosity, are the latency/throughput tests done with both libmapper signals and non-libmapper OSC running?

[aburt2]

yes they are, still need to test them individually, what I don't get, is if I'm dropping packets shouldn't I also experience a drop in the OSC throughput as well

[malloch]

yes they are, still need to test them individually, what I don't get, is if I'm dropping packets shouldn't I also experience a drop in the OSC throughput as well

There would be a drop compared to transmitted packets but throughput might still increase if the drops are intermittent. It might make sense to transmit an incremented counter and check the received values.

[aburt2]

@malloch I've tested this before between 2 ESP32 Boards and got around 2-3% packet loss when connected to a router with no other devices on the network and 30-50% packet loss when connected to the rasberry pi 4 (T-Tree at IDMIL).

Even the best case scenario has much higher packet loss in comparison to OSC which was 0.01%-0.05% packet loss under similar conditions. I'll test with this firmware on the ESP32S3 and see the packet loss when connecting to my laptop.

[malloch]

@aburt2 thanks for testing this! I have a few questions...

1. Which version of libmapper are you using? (there have been some recent optimizations)
2. Was this testing done with the call to mpr_dev_update_maps() included?
3. I notice the call to vTaskDelay() in loop() is commented out – is there another delay being called somewhere in the function or are you just running loop() as fast as possible?
4. the OSC bundle sizes created by libmapper and plain-OSC are likely different since updates to brush/multibrush, rub/multirub, shake, jab, count, tap/dtap/ttap, and battery are gated for plain-OSC but always included in libmapper updates. Perhaps the OSC bundle created by libmapper is becoming large enough to cause problems with the ESP32 networking stack? If you have time could you add the same update gating to the mpr_sig_set_value() calls and re-test?

Thanks!

[aburt2]

Hello Joe to answer your questions.

1. The ESP32 boards are using the libmapper-arduino library which is still using libmapper v2.3. I can't remember what version of libmapper I was using on my laptop it was at least libmapper v2.4.
2. There was no delay the messages were sent as fast as possible.

For your other two questions, this initial test was done just between two esp32 boards sending a counter. I haven't gotten around to testing the mpr_dev_update_maps() call or on the T-Stick just yet. Just wanted to give an initial update. I'll do what you suggested in point 4 when testing on a 5G T-Stick.

[aburt2]

@malloch

[malloch]

Thanks @aburt2 for the information – could you share the esp32 firmware you used for the test? I'd love to replicate & debug this issue.

[aburt2]

I had this firmware running on the ESP32 boards: https://github.com/aburt2/TStick-tester/tree/main/firmware/Wifi%20Testing%20(Libmapper)

I read the data via the serial monitor and analysed it.