Remove tx and rx buffers from client class about adafruit_cc3000_library HOT 6 CLOSED

the problem is the huge overhead for a single-character recv() - the 5ms timeout seems short but it adds up hella fast since select does not return immediately. the tx buffer im ok with turning static. if you want to do one at a time, test each and then submit a pull.

from adafruit_cc3000_library.

Let me try a few tests, if there's data available to read I suspect the select call should return very quickly instead of waiting the full 5ms. Are you concerned about the 5ms timeout when there isn't data available to read?

An alternative to still buffer reads would be to move the buffers from each client class instance, up to a global list of buffers (and buffer indices) indexed by socket. This way each client instance just has a copy of the socket id it deals with and uses the global buffer to read data for the socket. That way multiple clients can read data for the same socket without running into issues. The downside is that unless we want to dynamically allocate these buffers (might be too risky for a library to do) they would have to be allocated up front and take max number of sockets (technically 4, but maybe higher) * ~64 bytes of memory whether you use them or not.

from adafruit_cc3000_library.

IIRC it does not return immediately if there is data, it always takes 5ms

from adafruit_cc3000_library.

I did a little investigation to get some data. Here's the test I made: https://github.com/tdicola/adafruit_cc3000/tree/master/Rxspeed

I timed 4 types of API calls (with 1000 calls to each API) on my Arduino nano:

• select() call when all data is available
• select() call when only 1 byte is available
• select() call when no data is available
• CC3000 client library available() call when all data is available in the rx buffer

For the select calls I used the same 5 millisecond timeout the CC3000 client's available function uses.

Here are the results:

• select() call when all data is available

  Total execution took 634912 microseconds, or about 634 microseconds for each select call. This is a good because it seems the select() call isn't waiting the full 5 milliseconds to return.

• select() call when only 1 byte is available

  Total execution took 633240 microseconds, pretty much the same as the above case. Not a huge surprise because it's likely the same scenario/code paths as above.

• select() call when no data is available

  Total execution took 4985964 microseconds. This is almost exactly the expected 5 seconds it would take with each select call taking the full 5 milliseconds to return--no big surprises here.

• CC3000 client library available() call when all data is available in the rx buffer

  Total execution took 18788 microseconds, or about 18 microseconds per call. Since these calls are just comparing a few indices in the program's memory it's super fast as expected.

It's good to see select doesn't wait the full 5ms when there's data available and instead takes about 0.6ms to return. That said, 0.6ms is still quite a bit slower than 18 microseconds for the client library with rx buffering today.

What do folks think, is the memory trade off of buffering reads in the library worth it for the bump in speed? My 2 cents: keep the buffering out of the library and if a user needs the most speed possible, they can do the buffering themselves by calling the overload of read that allows filling a buffer. This would let the library users decide if the trade off of memory vs. speed for buffering is worth it. This seems similar to how the ethernet library is implemented too--it doesn't do buffering and exposes single char and buffer filling read calls.

from adafruit_cc3000_library.

As an example of how we can implement a server interface while still allowing buffering in the client, take a look at this pull request: #30

The functionality is almost exactly the same as the Ethernet library's server interface--the only difference being that I made a new client reference class to hide pointer semantics from users. This could be a good first step to server support without having to commit to any changes to buffering logic right now. I thought about other options like global buffers, but didn't want to do anything that would increase memory usage or require a lot of client class changes. If buffering logic does change in the future and client instances can be copied, this implementation should be forward compatible to just be typedef'ed into the client class.

The nasty issues with copying clients that are in my initial comment are still relevant and worth addressing, but don't need to block adding server support like this.

from adafruit_cc3000_library.

The server interface has been pretty stable for almost a year, so I don't think the priority of removing this buffering is that high. Closing the issue now.

from adafruit_cc3000_library.