AccuTracking

AT,
Just wanted to know what happens if the cached records reaches the limit set for cache?
For example:
Interval: 1 Min
Cache: 400
The unit is not updating in real time and there are no cached locations showing as well, if the total cached records reaches 400 what happens after that?
Also, does a full cache make the unit not update in real time as it keeps on trying to upload cached records....

Real-time data has priority. So the phone will always try sending real-time data first, then try the oldest cached data.

When the cache is full, oldest data are discarded first.

ATSupport wrote:Real-time data has priority. So the phone will always try sending real-time data first, then try the oldest cached data.

When the cache is full, oldest data are discarded first.

AT,
The unit came online or started updating again.
But here is what is really happening:
The unit came back at 1107 hrs.
There was no data (cached) showing at that time.
The unit is set to update at 1min intervals.
From 1107 to 1227 there are only 8 realtime updates, but the cached data is coming in hoards (Starting with the first at 1802 last evening.)
At this time, the real time is not updating, but with every refresh of the browser, all the cached data is filling in.
The cached enteries are at 1 min interval as well, so I am thinking, that somehow the cache is taking over the connection and is not allowing the real data to flow, if I am not wrong I read someplace that the interval for upload of the cached data is about 3 sec, so that is what is going on.... the unit is uploadng the cached data as fast as it can, in the mean time when the exact time comes for the real data to be sent, the connection is busy sending the old data, so the real time and position also gets posted into cache., this becomes a catch 22 loop, with the real data only getting posted when the cached is not being sent at the exact time of the real data posting and the connection to the internet is free. But if the connection is not free, then the real data gets in line on the cache.
This is resulting in sporadic updates in real time, and I am sure that after all the cached data is posted, the real time postings will fall in line with the 1 min intervals.... I am going to keep a watch and report on that as well.

Please check this out and advise.

Actually your analysis makes sense. I know the cache sending and real-time sending are on different threads so they can occur without blocking the other. But they eventually share the same wireless channel and that might be the bottleneck.

However, even if the cache sending blocks the real-time sending, it won't block that long: assume your cache size setting is 200, for a send at every 3 seconds, a full cache can be depleted in 10 minutes (might be a bit more considering the connection delay). The cache sending thread would immediately stop sending if the connection failed and yield the connection to the next real-time refresh and sending.

ATSupport wrote:Actually your analysis makes sense. I know the cache sending and real-time sending are on different threads so they can occur without blocking the other. But they eventually share the same wireless channel and that might be the bottleneck.

However, even if the cache sending blocks the real-time sending, it won't block that long: assume your cache size setting is 200, for a send at every 3 seconds, a full cache can be depleted in 10 minutes (might be a bit more considering the connection delay). The cache sending thread would immediately stop sending if the connection failed and yield the connection to the next real-time refresh and sending.

I think I set the cache size to 600-800, so it is going to take a while to deplete, I will have to change that. It is still going, with the cache filling up pages and real coming in sporadically. Since the interval is set to 1 min, let us assume that there are 50-55 records per hr in cache, so it will take time to deplete.
I have a question, if I enable Smart Sending, will that take care of the issue? I read in the forums that Smart sending does not report real position.. is that true???

Enabling smart sending will reduce the number of real-time data as it blocks "duplicate" data. They are real positions. What you read about the smart sending is a different issue: in plain words, when the phone is coming to stop from a low speed (i.e. 5mph), the smart sending blocks the last stationary position.

ATSupport wrote:Enabling smart sending will reduce the number of real-time data as it blocks "duplicate" data. They are real positions. What you read about the smart sending is a different issue: in plain words, when the phone is coming to stop from a low speed (i.e. 5mph), the smart sending blocks the last stationary position.

Like I said before, the moment the cache caught up with the first real time data this morning, the updates are happening in 1 min intervals now. In addition you can see when the unit tried to send in real time but could not because of the bottleneck, as they appear as cached records.

I am going to reduce the cache size, and see if that helps... or enable Smart sending...
But this still does not explain why the unit stops in the evening as I stated in another thread...

Also in your openion, what would be the best settings for Cache and send interval so that this bottleneck does not hinder the updates???

narcotics3 wrote: But this still does not explain why the unit stops in the evening as I stated in another thread...

I would then seriously doubt the cell tower malfunction in that area.

For now you can lower the cache to a few hundreds and interval unchanged. We'll see if we can improve this in the next version, i.e., yield the connection to real-time data from time to time. Thanks for your great input!