[LU-445] Send timestamps with LNet counters

• Type: Improvement
• Resolution: Fixed
• Priority: Blocker
• Fix Version/s: Lustre 2.3.0
• Affects Version/s: Lustre 2.3.0
• Bugzilla ID: 22,639
• Assignee: Doug Oucharek (Inactive)
• Reporter: Wally Wang (Inactive)

Description

We should send the timestamp data from the node along with the performance
counters. This will give us much more accurate performance data on a per-node
and per-group basis.

This is originally discussed in Oracle Bug 22639.

Comments

[Wally Wang (Inactive)]

http://review.whamcloud.com/#change,3514 is the 1st patch for b2_2. Will submit the 2nd patch after landing this one.

[Doug Oucharek (Inactive)]

Change http://review.whamcloud.com/#change,3192 has landed thereby addressing the backwards compatibility issue.

[Liang Zhen (Inactive)]

Change it to blocker

[Liang Zhen (Inactive)]

Please be more cautious about this and use at least 500 as the value, we can't use interval less than one second, even milliseconds stamp could not be so accurate but it shouldn't be less than 500.

[Doug Oucharek (Inactive)]

Ok, checking programmatically makes sense. Based on Liang's comment, I'm assuming I can use 100 as the value to check the timestamp against to determine whether to use local or remote timestamps.

[Liang Zhen (Inactive)]

Yes we can distinguish this by value, the minimum interval of stat request would be 1 second which is 1000 milliseconds, but number of running tests on a node is almost impossible to be larger than 100.

I thought about this at the beginning, but felt it could be confusing for code maintainers (OK, we are the maintainers), that's the reason I suggested Doug to fix by current way.

However, I agree user will like it more if it can automatically decide which timestamp to choose, so if you think it's kind of acceptable style, I will not object to choose the easier way.

[Liang Zhen (Inactive)]

Yes we can distinguish this by value, the minimum interval of stat request would be 1 second which is 1000 milliseconds, but number of running tests on a node is almost impossible to be larger than 100.
I thought about this at the beginning, but think that could be confusing for code maintainer (OK, we are the maintainers), that's the reason I suggest Doug to fix by current way.
However, I think user will like it more if it can automatically decide which timestamp to choose, so if you think it's kind of acceptable style, I will not object to choose the easier way.