Comments (6)
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.
Related Issues (20)
- Server doesn't support UDP or Datagram HOT 6
- Larger data packet than available buffer causes memory overwrite
- fastprint hang (buildtest fails to ping) HOT 2
- Error -85 getting when trying to connect CC3000 to any webserver
- WebClient example crashes on large file downloads HOT 13
- compiling issue in Eclipse CDT HOT 1
- fastrprint sometimes returns negative values HOT 1
- Arduino Due HOT 1
- Does not reconnect automatically
- Client objects are not marked as disconnected when disassociated HOT 1
- Adafruit_CC3000_Client disconnects after a few minutes HOT 1
- intermittant hangs in read loop HOT 9
- Release 1.0.1/1.0.2 contain version 1.0.0 in library.properties HOT 1
- CC3000 can't connect with MQTT broker using IPAddress Object
- fastrprint crash on long string
- Support for Arduino IDE >=1.6
- Use vendor zone for pool.ntp.org HOT 1
- Sending sensor data to pc via arduono and adafruit cc3000
- Sending sensor data to pc via arduono and adafruit cc3000
- freegeoip.net doesn't exist any more HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from adafruit_cc3000_library.