Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

portstat shows negative counter for RX_OK #129

Open
pavel-shirshov opened this issue Oct 11, 2017 · 1 comment
Open

portstat shows negative counter for RX_OK #129

pavel-shirshov opened this issue Oct 11, 2017 · 1 comment
Labels

Comments

@pavel-shirshov
Copy link
Contributor

pavel-shirshov commented Oct 11, 2017

:~$ sudo portstat
Last cached time was 2017-10-11 19:00:26.387868
      Iface    ADMIN    OPER        RX_OK       RX_BPS    RX_UTIL    RX_ERR    RX_DRP    RX_OVR       TX_OK        TX_BPS    TX_UTIL    TX_ERR       TX_DRP    TX_OVR
-----------  -------  ------  -----------  -----------  ---------  --------  --------  --------  ----------  ------------  ---------  --------  -----------  --------
Ethernet116       up      up     -584,110  9725.13 B/s      0.00%         0   586,217         0  72,208,263  4624.59 KB/s      0.09%         0  377,228,521         0
@jihaix
Copy link

jihaix commented Jul 15, 2019

  portstat show counter's value in two mode, namely absolute mode and relative mode .
  When running command portstat -c, the value of counters will be saved in tmp file and portstat run into relative mode. In relative mode , portstat will show the diff between counters' current value and old value saved in tmp file, namely print(current - old). When running command portstat -D, portstat will clear tmp file and run into absolute mode. In this mode, portstat will show the absolute value of current counters, namely print(current).
  So, portstat shows negative counter because it's in relative mode and its current value is smaller than old value saved in tmp file . There are two logical possiblities, one is the RX_OK's value is lagger than uint64 and integer overflow happends in sonic-syncd, which is very unlikely. The other is the RX_OK's value provided by SAI is less than uint64 and integer overflow happends in SAI or SDK, which is very likely. So you may check the register's bit width provided by SAI and SDK.

vdahiya12 added a commit to vdahiya12/sonic-utilities that referenced this issue Jul 23, 2021
…r conditions/events (sonic-net#129)

* [xcvrd] Fix y_cable state update to unknown on erroraneous events

This PR provides the support for replacing the state DB updates from 'failure' to 'unknown' in case there is an error event in the functioning of Y cable
What is the motivation for this PR?
the schema agreed upon with linkmgr and orchagent interaction with xcvrd, is that if there is an error event xcvrd need to fill the state DB with 'unknown' as the state value rather than 'failure', this PR handles that

How did you do it?
identified error scenario's in the code and made the changes

Signed-off-by: vaibhav-dahiya <vdahiya@microsoft.com>
stepanblyschak pushed a commit to stepanblyschak/sonic-utilities that referenced this issue Apr 28, 2022
 Update transceiver info DB key names (sonic-net#146)
[Multiasic]: Provide namespace support for ipNetToMediaPhysAddress (sonic-net#129)
[LLDP]: Modify OID index of LLDPRemTableUpdater MIB (sonic-net#155)
[Namespace]: Simplify sync_d functions to use higher order (sonic-net#154)
[Namespace]: Fix interface counters in RFC 1213 (sonic-net#145)

Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants