maximum frames

[onecamaro1]

Hi guys,I did a search on anything related to this and found nothing. So here we go, I am trying to log afr error% (tuning VE via WB) and the resolution is great.The framerate is super fast and i actually like it but, it cuts off after 65,000 frames and i haven't gotten home from work yet. I don't want the framerate to decrease, but is there a way to log longer? I drive about 1 1/2 hours from work to home. Any help on this? I know efi live logs as long as you have it on. Ohh, i always leave my laptop hooked up to it, so shouldn't it be writing to the HD anyways?

[EC_Tune]

That is the current limit for log files.

[onecamaro1]

Thats approx. 27 minutes. Is there any talk to let logs go straight to the drive?

[EC_Tune]

Don't know at this time. I usually fill the table view with PIDs so there is more data per frame. Then you can log a bit longer.

[Bill@HPTuners]

I think, and don't quote me on this, its a memory usage thing. Remember, we do have a minimum requirement so when we compile the software we need to make sure people with a 400mhz computer can log those 65000 frames of data without issue. Going over that datapoint might not be possible unless we raise the minimum requirements which we really don't want to force everyone to have the latest & greatest in laptop technology just to run our scanner.

-Bill

[jknox]

It's probably not a memory issue (directly, anyway). At maximum data logged (40 bytes per frame) the memory required is only 2,621,440 bytes (or 2.5 MB).

Instead, it's probably the size of the variables used to hold the frame count information. A 16-bit data variable has a max value of 65,535, and that just happens to be the real maximum frame count (I've hit it myself to see). Mind you, with 24 bytes logged (which is what everybody seems to recommend) which nets you 10 frames/second, this is worth 109 minutes of log data.

I don't know how many places the code would have to be massaged in order to bump the counter size to 32 bits, but I'd suspect it's a fair number. I imagine most people would rather the boys work on things like Auto-tune instead...

[Keith@HPTuners]

bingo, we have a winner!

Surprisingly though, our Editor and Scanner engines are very powerful.. We've learned alot over the years, from vcm suite 1.0, 1.1, 1.2, etc... all the way to 2.0.x, 2.1.x, to 2.1.18

When I last updated the hpl log file format, I forgot to allocate another byte of storage for the # of frames.

Thinking about this has just given me a few ideas for semi-dynamic max frame limits.. something to look into after 2.2.0 .... or at 3am tonight when I want to see how it works.

Thanks!

[bilemke]

Sweet.. I like taking long logs too..

Cant wait to see this.

[jknox]

Thinking about this has just given me a few ideas for semi-dynamic max frame limits.. something to look into after 2.2.0 .... or at 3am tonight when I want to see how it works.

You must get bored easy.

Heck, bumping up to 24bits would give 466 hours of log at 10fps. 19 Days is a heck of an endurance run! Out of curiosity, what advantage would there be to semi-dynamic that is worth the extra code complexity? Or would that be a SEKRIT?

[Keith@HPTuners]

Well, the advantage is a "rolling" upper frame limit that allows more powerful computers to log almost endless amounts of data without having the up front mem alloc impact that would hurt slower computers.

Hopefully soon everybody is running a dual core laptop and we won't have to worry about resources anymore, that will be the day!

[onecamaro1]

Thanks guys. I didn't expect this much feedback, but you are great. The reason i bought HPtuners is that its more powerful than the rest, just was noticing that my efilive could log forever and i didn't want to drop resolution for time on your scanner. I normally use only 3 pids when i do VE because i'm using a WB. I'll be waiting, thanks again.

[bilemke]

Well, the advantage is a "rolling" upper frame limit that allows more powerful computers to log almost endless amounts of data without having the up front mem alloc impact that would hurt slower computers.

Hopefully soon everybody is running a dual core laptop and we won't have to worry about resources anymore, that will be the day!

Dual core and 2gb of ram here.

[jknox]

Ah. Incremental memory allocation. Makes sense. I got stuck on manipulating the size of the array offset.

I think there would be plenty of power available. I don't know much about heap allocation in .net (I'm used to straight C in microcontrollers), but just considering that my laptop (a 1.6 M-series) can do 100Mbps packet captures without issue I wouldn't think you'd have much trouble there. Memory for that is prealloc'd for certain, but it's still has to shove as much as 10MB/sec. For the current generation of ecms I don't think you come close to 1K/sec yet...

See what happens when you let geeks run loose?