jfitzpat

I thought in his first post he mentioned this. 50 samples in a pull with Mitsulooger alone, 6 samples when he runs both together.

-jjf

krillin

iTrader: (3)

yeah i've run it alone and along with zeitronix. only happens when i run with zeitronix at the same time, and i've been able to log fine for months. you can ask bryan (earlyapex). i've emailed him several of my logs for evaluation.

MalibuJack

iTrader: (5)

Yeah brain fart.. Whoops..

MalibuJack

iTrader: (5)

I really don't know what could have changed..

Out of curiosity, what com port #'s are the two ports assigned as?

Although this is kinda rare and weird, since you reinstalled ECUFlash the com port assignment might have changed. If your hardware com port is COM1 and ECUflash cable is COM3, (Or Com2 and Com4) its "POSSIBLE" there's some sourt of resource conflict. Back in the day of physical hardware, those ports would share an interrupt. I doubt this to be a valid case, but if you see either of these combinations, then I'd suggest at least changing the ECUFlash cable com port to something else.

There's really no link otherwise that I can think of.

jfitzpat

Since the USB hardware shares the interrupt for the USB controller (typically built into the chip set), this sort of conflict is largely gone. However, you can still sometimes get a software conflict (that is what I referred to as a rare case above). The FTDI driver is still assigned a COM#. Sometimes, it is possible to get two devices assigned the same number. Things mostly still work, but the com stack, at least up to XP SP2, gets confused.

-jjf

krillin

iTrader: (3)

well, i was just messing around with different ideas last night. i tried logging then minimizing both windows (mitsulogger & zeitronix) and i seemed to get my samples back. i was checking the processes for both programs while logging. it seems that mitsulogger likes to use around 30-35% of the cpu by itself, while ZDL (zeitronix data logger) likes to use around 60% by itself.

if i shrink the ZDL window down then the cpu usage will go down as well. if i have zeitronix completely minimized, the cpu usage drops extremely low; i think below 10%.

so i guess the ZDL software is the cause. although i don't understand how i was able to log at fullscreen and not have any sampling issues.

i'm running an older version of ZDL right now (2.0.5 i believe). i THINK at fullscreen this version only went as high as 40%, but it was late and i didn't have time last night to test mitsulogger and this version at fullscreen yet. maybe this p3 500mhz laptop isn't quick enough to handle both loggers at the same time.

jfitzpat

As I mentioned earlier in the thread, if there aren't any common drivers or kernel resources involved, drawing is the most common form of deadlock. 500 MHz is plenty for the serial ports and the logging, even with floating point conversion computations. What it might not be enough for is drawing. I know this sounds counter intuitive, but think of WinAmp. You'd think playing audio would be the big thing, but most the codecs are a very good fit for the CPU. It is actually turning off the fancy skin that allows the app to continue to run on older machines.

You might want to double check all your display and performance settings. Hardware accelleration in drawing for your display adapter may have somehow gotten turned off. Depending on how it is drawn, something as simple as a gauge needle can go from 0-1% of CPU time to 50% or higher if there is no accelleration support from the display driver.

-jjf

MalibuJack

iTrader: (5)

Well, I guess its being drilled down at this point so I won't suggest anything further, I didn't want to say anything about the display at the time but it makes the most sense as I've seen some slower machines choke on busy redraws of windows, especially graphing.

It still doesn't explain what changed recently for that to be different, other than perhaps you changed resolution, increased bit depth, updated video drivers, or some other weirdness.

As long as minimizing the app works, then at least you have a workaround. I do know that Mitsulogger doesn't have a huge GUI performance hit, its window sizes and amount of data thats updated at any one time was done that way for a reason (to prevent dozens of cells updating)

MalibuJack

iTrader: (5)

I have actually seen this also, additionally I've seen USB/Virtual devices assigned Com3, have some performance trouble if a hardware port is on Com1, again, they have no relationship, at one time they might have shared an interrupt if it was hardware, but who knows what weirdness XP is doing under the hood.

Obviously this might not apply anyway as he seems to have done a bit more troubleshooting and noticed the GUI being a performance hit.