Gary Rubin

My platform is a laptop with one eSATA port -- so only 1 drive. For rev2 I might be able to look at getting an ExpressCard SATA card with a couple ports and trying a RAID setup.

There are a bunch of eSATA external RAIDS listed on Newegg. I don't have any personal experience with them, but it looks like some use a single eSATA port. Based on the Newegg reviews, it also looks like you get what you pay for.

Process Explorer will list threads associated with an application. There is a lot of information provided about each thread, but it's not clear what it all means. Does anyone know if it's possible to relate a Process Explorer thread to a LabVIEW thread (e.g. Data Acquisiton, Standard, etc.)?

Gary

Have you configured your connection to set TCPNoDelay?

Thanks for the heads up! BTW, upgrade to Firefox 3.5. You're out of date already.

Upgraded to 3.5 and now the Reputation looks better, but the Profile page still looks screwy.

In the "Today's top posters" list, what's the definition of "today"? It seems to be counting yesterdays posts too.

Thank you for the fun of this link.

Very good musical.

I just send a link to my friend Tony!

Did I miss something?

This amounts to streaming to disk at somewhere in the neighborhood of 56MB/s. My disk can only keep up with that until it's about half full.

I haven't done any exhaustive testing (like filling up the disk), but we've gotten good write speeds using a 2-disk SATA RAID. Is something like that an option?

Gary

No big deal, of course, but I see vertical alignment problems in a couple places.

In the Top Reputation section on the front page, the reputation count doesn't line up with the names.

Also, on my profile page, the Version and Since parts bleed down into the Recent Visitors.

I can provide screenshots if you want.

I'm using Firefox 3.0

at the LAVA BBQ though...

Speaking of which, the Salt Lick was on the Food Network a couple weeks ago. It made me think of you all.

Mike,

STFF man! (search the freaking forum)

Someone came up w/ a very similar way as REx to use queues over a network or at least that's what I found on lava search.

Is this what you're talking about?

It refers to an attached file, but I don't see one. Michael, did attachments not port from LAVA 1.0?

I'm a bit busy putting together NI Week presentations about OO features at the moment, but if I get time next week, I'll try to write up a big summary document of queues and notifiers, pulling together all the various parts I've posted over the years.

Thank you. I (and I'm sure many others) would appreciate that.

If you're taking requests, I would love to learn more about queue operation/performance/optimization when passing relatively large chunks of data. My queue elements are smaller than the 1.5MB that Cat mentioned, but I feel like my application is somewhat similar to hers. Much of what I've read previously on LAVA seemed to concentrate on queues for messaging rather than data passing.

Thanks,

Gary

I've always had an expectation of Single Element Queues to be the most memory efficient and fastest way of getting information from point A to point B by reference.

And that if you do a modification of that element, by DeQ, modify, EnQ that you will be doing an in-place memory operation. This makes me think otherwise unless the compiler is as smart as we hope.

I'm going to guess that the answer is yes, provided that the element is the same size as it was before. Just a guess, though.

Suppose you have a queue of arrays of 32-bit integers. The queue is filled by 20 arrays each of 100 elements. If you flush the queue, the queue will simply note that its current buffer index is zero and the length is zero, but no elements will actually be deallocated. No help there. But if you flush the queue and then enqueue 20 empty arrays, the bigger arrays in the queue buffer will be deallocated, giving you a bit over 400 bytes of memory back, but the queue buffer itself, 20x(size of pointer [4 bytes on 32 bit machine]), won't be deallocated unless the queue is destroyed.

Having a little trouble following this. Let's see if I have it right.

A queue is an array of memory pointers. When you enqueue, memory is grabbed for the data, and it's grabbed for the pointer. As more elements are put into the queue, memory allocations have to occur for both the pointer array and for the data.

When a flush occurs, LabVIEW runs through the pointer array, grabs the data that each element is pointing to, and packages everything up and puts it out on a wire. It then sets a write pointer and read pointer (or something similar) back to zero, but doesn't actually do anything with the memory.

Here's where I get confused:

The next time data is enqueued, there will be no memory allocations necessary for either the pointers or the data, so long as you don't enqueue more data than was there before the flush?

Now, with what you described, enqueing the empty data array deallocates the memory space associated with the data. First, how is that different from subsequent enqueues with different data length? Is there actually memory management going on whenever an enqueued element is of different length than the element that was previously at that queue location?

Second, wouldn't your recommendation to Cat defeat the purpose of the flush not automatically deallocating?

A while ago, Ben made a suggestion of preallocating queues by enqueueing a bunch of data, then flushing it. I'm beginning to get the impression that unless each queue element is the same size every time, this only preallocates the pointer array, not the actual data space. Is that true?

There are still no PCI versions of these cards yet

I agree with that frowny-face. We were looking at a Flex-RIO card for an application. The card's capabilities would be perfect, but the fact that we'd have to add a PXI box is a problem.

CRelf, can you point to any of these PXI-to-PCI adapters you're talking about? I think I've seen such things for 6U cPCI, where the card cPCI card sticks up like a double-height PCI card (and you can't put the lid on the compuer). Is that what you're talking about?

Maybe it's trying to tell you that you ought to jazz your lists up a bit. After all, word lets you customize the bullet symbol for bulleted lists...

Your lists could be:

More lively

More interesting

More distracting...

Gary

Eugen,

To change your display name, click your name up in the upper right corner and select My Settings. That will bring you to a screen where you can change your display name.

Gary

Gary, we're working on importing the old content. In the meantime, feel free to start new topics.

Thanks for all the work. This looks pretty impressive.

One other question. I noticed that this topic has 1 reply and 0 views. The old LAVA used to show the same odd statistics. Does the View counter update less frequently than the Reply counter?

BTW, it's funny to see you with "Newbie" under your name.

Mike, is the old content gone forever?

In some cases (i.e. Alfa thread) that might not be a bad thing. What about all the great nuggets and assorted LabVIEW wisdom?

Gary

Done. Great story!

It reminds me of my friend's wedding; I wondered whether I was the only one who thought it odd that they entered the reception to "Bittersweet Symphony"

Thanks. I'll have to give those a try. Because out external NAND gate does the job, this has become somewhat lower priority for now. When I have an opportunity, though, I'd still like to see if it's doable.

QUOTE (peteski @ May 22 2009, 07:21 PM)

Nice catch, ShaunR! That should be able to make it work. I forgot all about the Gate functionality.

As far as I can tell, and someone can correct me if they've gotten this to work, is that the Gate applies for input counters, the Pause is the equivalent for output counters (i.e. pulse generation).

QUOTE (cbolin @ May 22 2009, 10:15 AM)

I am assuming the "At this time, we presume that the suggestion indeed solved your issue" email was a survey email. One of the best ways to provide feedback (positive or negative) to AEs and their managers is through the NI surveys

Yes, I did fill out the survey. You can't complain if you don't provide feedback, right?

QUOTE (peteski @ May 22 2009, 10:21 AM)

Pete,

I would certainly appreciate any wisdom you could provide.

The original post here describes what I was trying to do.

Thanks,

Gary

Thanks for the advice, Ben (as always).

I understand that, as you indicated in #2, it's important to let the AE know that they're talking to someone with LV programming experience. Given the marketing thrust embodied by the Express approach, I'm sure a large portion of calls to the AE line are from novice users and can be solved by simply pointing the caller toward available resources.

I am sympathetic to the AE's. How do they know the technical level of the caller? Talking to a novice user as if they were a LV expert isn't helpful, and talking to an experienced wireworker as if they were novices leads to grumpy people like me. Just asking the caller about their level of expertise isn't particularly helpful either, as the response isn't very well calibrated. I guess that's where the field engineers come in - they supposedly know their customers better.

<rant>

So, as some regular readers may know from my previous posts, I spent a few days last week struggling to figure out whether my PCI-6601 Counter/Timer board was capable of performing the pulse generation that I was trying to do. After striking out in my attempts to find applicable examples or knowledge base articles, I tried posting here and at the NI forums. At the suggestion of Ben and our local field engineer, I called NI's application engineers. The application engineer just refered me to the same knowledge base articles that I'd already found. When I pointed out that none of these really did what I was looking for, he concluded that what I wanted to do might be possible, but it would be up to me to decide whether figuring out would be a good use of my time.

Now, fast forward a week. I gave up on trying to make the 6601 do what I need. Instead, I'm using an external NAND gate to operate on the 6601 output and everything is working fine. This morning, I got an email from NI that starts as follows:

QUOTE

One week ago, our Application Engineer suggested a resolution to your service request number XXXXXXX. At this time, we presume that the suggestion indeed solved your issue.

Does anyone else find that second sentence somewhat off-putting? Just because an AE spent 15 minutes talking to me, saying "Read this. Read that." doesn't mean that he solved my problem.

What rubs me the wrong way is that implication in that email was that a) NI's documentation is so clear and b) the customer is so naive that all it takes to solve a problem is to politely tell someone to RTFM (or in this case "RTF Knowledge Base"). At least that's how I read it.

I think "we hope we helped", rather than "we presume we helped" would be a much less arrogant way of dealing with customers.

As far as I recall, this is my first question to an AE - maybe others have had better results.

</rant>

QUOTE (jdunham @ May 18 2009, 12:51 PM)

I agree that what NI defines as "foreground" and what they call "background" is not intuitive, especially for booleans,...

I think you could go so far as to call it "counterintuitive".