VMPDataAvailable bitrate asymetry between channels

[jpapale]

Hello,

I've implemented features which rely on 'void ApplicationIo::VMPDataAvailable(VeloMergeParserDataAvailable & Event)', inspired by another topic from this forum.

It works fine, but I'm observing something that sounds odd to me: Channel 0 get around twice more data than Channel 1. However, data are consistent on both channels.

How would you explain that observation?

Thanks.

[jhenderson]

When this data is logged to a disk file and analyzed by Binview, does the asymmetry still exist? I suspect there is something wrong with either your parser code or the underlying VeloMergeParser object.

[jpapale]

Yes, the asymetry also exist when reading the data with BinView. Its not obvious with the default number of samples, but starting from 1M samples, I can see the trace of the channel 0 is complete, while the one from channel 1 is 'flat' starting from around 80%.

[jhenderson]

Please upload your Settings.ini file from the directory containing the executable for analysis. I suspect that you are attempting to log data faster than your host system can sustain. To verify this, enable the input overrun alert and repeat the test. If the input overrun alert is signaled, then you are exceeding the real-time capacity of your host system.

[jpapale]

Hello,

Please find attached the Settings.ini, a screenshot of the issue and the VMP data. Note that a quick check with the 'VeloParser' disabled show the same behavior.

The log of the run related, with all alerts 'On' is the following:

Preconfiguring Stream....
Actual PLL Frequency: 4e+008
Analog I/O started
Stream Mode started
Trigger 0x13030001 Type: Input after 1 master clocks
Analog I/O Stopped
Stream Mode Stopped automatically
Elasped (S): 0.070

I don't think it is related to a buffer overrun because if I provide an input signal, the data is consistent. Also, the computer is a i7 E610 with 3GB RAM, dedicated to the acquisition task, so it should be enough to handle the data.

[jpapale]

And here is the startup info, which may be relevant too:

System wordset loaded
ficl Version 3.03
Aug 17 2012
X6_400M-specific wordset loaded
ok>
Bus master size: Input => 4 MB Output => 4 MB
Module Device Opened Successfully...
Stream Connected...
Logic Version: 102, Hdw Variant: 0, Revision: 4, Subrevision: 4
Board Family: 2, Type: 2, Board Revision: 1, Chip: 0
PCI Express Lanes: 4

[jhenderson]

When Autostop is enabled, the application software issues a stream stop command to the card after SamplesToLog bytes of data have been received. The time required to halt the stream is system dependent, so it is impossible to control or predict how many packets of data will be received from each logical data source (SID).

It appears that you have received less ch1 than ch0 data. But, try capturing a longer data set and I suspect you will find that both channels are evenly populated until near the end of the dataset. This is an unavoidable consequence of the default firmware implementation. If you wish to precisely control the amount of data acquired, use Framed mode triggering.

[jpapale]

I can tell it is not related to the 'AutoStop', because I've added additionnal code in 'VMPDataAvailable' which decode the header to find out which channel the data is related to. And there, I can see the amount of data is way bigger for channel 0 than for channel 1, already when we receive the stream.

I'm not talking about dozens of frames of discrepancy, which is a mismatch I can perfectly understand. But it's about mega bytes, already appearing during the logging. I've attached a longer run, so you can see by yourself.

Here is the related log, again with all alerts enabled:

Preconfiguring Stream....
Actual PLL Frequency: 4e+008
Analog I/O started
Stream Mode started
Trigger 0x13030001 Type: Input after 1 master clocks
Stream Mode Stopped automatically
Elasped (S): 1.337
Analog I/O Stopped

[jhenderson]

The current logic version is 1.07, but your board is reporting 1.02. Please download the latest beta package for the X6-400M and use VsProm to update the firmware. Power cycle the PC and retest using the latest firmware and software. [/u]

[jpapale]

Done. Note the firmware of the latest beta reports a v1.08.

The asymmetry is now gone, good catch. But the acquistion now requires two 'Start' to actually start. It looks like the software trigger is not taken into account the first time. Is that expected?

Two other points which seems odd to me, which are left unchanged with this new firmware, that I've noticed when enabling the Alerts:

-I get sometimes, almost immediatly after the acquisition start, the following:
Input FIFO overrun 0x13030002 after 273227469 master clocks
Input FIFO overrun 0x13030001 after 273229285 master clocks

-Also, the timestamp rollover units seems strange to me. I doubt it takes only 10 master clocks to rollover:
Time stamp rollover 0x1 after 10 master clocks
Time stamp rollover 0x2 after 10 master clocks
Time stamp rollover 0x3 after 11 master clocks

[bjackson]

It should not require hitting 'start' twice in order to start it. Make sure that you have the latest software from here:

http://www.innovative-dsp.com/cgi-bin/dlWindowsBeta32.cgi?product=X6-400M

The FIFO overruns may occur because you are trying to stream 2 channels at 400 MHZ. With 16 bits/sample, that equates to 1600MB/sec. Below it shows that you are only using 4 lanes of PCIe, which would mean the very maximum data rate you would be able to achieve is 250Mb/s * 4 = 1000Mb/s. If you reduce the sampling frequency, you should not see this problem.

I am seeing the same thing here with the time stamp rollover. I'll look into why it is reporting this.

Thanks,
Brian Jackson
Innovative Integration

[jhenderson]

The time stamp rollover issue is merely an artifact of the reporting technique. Each time the timestamp counter rolls over, an alert is generated and the current time count value is latched. Naturally, since the rollover just occured, the time stamp counter value is very low and largely consistent at a value of approximately 10. The SW application is responsible for tallying the number of rollover events which occur - this is not maintained in the firmware.

[jpapale]

Thanks for your answers.

About the timestamp, I understand the 'master clock' value isn't relevant in that context.

For the overrun, if I apply a sparsing by 2 or a sample rate of 200MHz, the overrun appears later. If I apply a sparsing of 4 or a sample rate of 100MHz, it looks ok. I'll have to check with the customer to see if that's acceptable or if we have to find a x8 backplane. What is the FIFO size?

For the 'Start' issue, I'm using the latest release, with the following versions:

MalibuRed = 1.78
Malibu = 1.69
X6-400M = 1.13

The beta version has the same values. Is it worth upgrading anyway? By the way, do you have a change log somewhere? That would surely help.

[jhenderson]

The stock firmware apportions one half of the onboard RAM as a virtual FIFO for host->target data streaming and the other half for target->host streaming. The board is equipped with 4 GB RAM total, so 2 GB in each direction.

The change log is located at http://www.innovative-dsp.com/support/update.htm.

[jpapale]

So, assuming the PC is not able to store any data on time, we should get at least 500 MSamples per channel of continuous data. Is that right?