These extra heartbeats can be a drain of up to 15 percent on CPU.
If DTCs are involved, flipping a switch on the transceivers can resolve the CPU drain. After flipping the SQE switch to on, excessive IO activity stops — and with it, the excess CPU activity it causes.
If the SQE heartbeat on the 10BaseT transceiver is not on, you can get a high level of disk IO, because the system wants to log each of these events. The IO can be significant, up to a continuous 70-80 IOs per second. Doing a LINKCONTROL @; STATUS = ALL can turn up heartbeat losses recorded since last reset. Turning on the transceiver's SQE heartbeat corrects the problem.
Somewhat randomly, we get a handful of heartbeat losses, carrier losses and transmit errors (same number of each). We can go for days without seeing any. We replaced the MIO card but it had no effect on these occasional glitches. I’d like to replace the transceiver because we see no other problems anywhere on our network. What are my chances of successfully doing this hot?
You can swap transceivers hot. In fact, Replacing the transceiver solves the problem.
What diagnostics and network reports should I trace to discover a transceiver's heartbeat problems?
SQE heartbeat loss can lead to all sorts of network and system performance problems. It's usually caused by a defective transceiver or a transceiver that has not been configured correctly The first thing to do is check for heartbeat losses on the LAN card. Heartbeat losses on the system card cause slow network throughput, most notable in large file transfers. The LINKCONTROL command can show you if the transceiver is not providing SQE heartbeat.