PNM : Modems data not returning EQ tap data.

Symptoms: The system was set up correctly and seemed to be functioning properly. It imported 4 cable modem MACs and street addresses in order to test the system.  It proved quite valuable.    It wasn't getting any Pre-EQ data from the modems even though it appeared everything was communicating properly.  This would produce errors in the PNM UI any time we tried to search for a modem MAC or the Node name.   After using some diagnostic tools and MIB browsers, the pnm-snmp.log file on the server all along includes the tips for this issue as it is described below:  (This file is also included in the .zip when you export the logs from the system)  2016-10-22 00:05:02,814  INFO [cmtsThreadPoolExecutor-6] (CmtsInformationCollectionThread.java:129) cmts:10.1.1.140, upstreams(16, Net:62 ms, DB:31 ms), modems(4, Net:109 ms, DB:15 ms), ModemToUpstreams(Net:32 ms, DB:0 ms), ModemToUpstreamNodeDB:32 ms2016-10-22 02:02:38,488  WARN [pool-28-thread-3] (CmSnmp.java:162) Skipping cm eq because of invalid data for modem 163848 , eq tap 04:01:08:00:ff:d9:ff:f3:00:45:ff:f2:ff:75:00:31:7f:ff:00:00:00:58:ff:ab:ff:e3:00:0c:00:1f:ff:e3:ff:e3:00:13 , tx 3552016-10-22 02:02:38,488  WARN [pool-28-thread-2] (CmSnmp.java:162) Skipping cm eq because of invalid data for modem 163846 , eq tap 04:01:08:00:00:1a:00:3b:ff:96:ff:e6:00:76:00:35:7f:fe:00:00:ff:22:ff:fd:00:7c:00:00:ff:af:00:09:00:2e:ff:f9 , tx 3452016-10-22 02:02:38,488  WARN [pool-28-thread-5] (CmSnmp.java:162) Skipping cm eq because of invalid data for modem 163845 , eq tap 04:01:08:00:ff:47:ff:f3:01:24:00:2e:fd:a5:ff:e8:7f:f3:00:00:01:d9:00:12:ff:18:00:1d:00:97:00:1f:ff:a3:00:00 , tx 3202016-10-22 02:02:38,816  WARN [pool-28-thread-1] (CmtsSnmp.java:355) Skipping cmts eq because of invalid data for modem 163848 , eq tap 04:01:08:00:00:00:ff:f0:ff:f0:00:00:00:10:00:10:3f:c0:00:00:00:10:ff:f0:00:00:00:00:00:00:00:00:00:00:00:00 , snr 361 cmts 1, upstrmIdx 0 docsis 02016-10-22 02:02:38,816  WARN [pool-28-thread-1] (CmtsSnmp.java:355) Skipping cmts eq because of invalid data for modem 163846 , eq tap 04:01:08:00:00:00:ff:e0:00:20:00:10:00:00:00:00:40:20:00:00:00:10:ff:f0:ff:f0:00:00:00:10:00:00:00:10:00:00 , snr 361 cmts 1, upstrmIdx 0 docsis 02016-10-22 02:02:38,816  WARN [pool-28-thread-1] (CmtsSnmp.java:355) Skipping cmts eq because of invalid data for modem 163847 , eq tap 04:01:08:00:00:00:00:00:00:10:00:00:ff:d0:00:00:40:70:00:00:00:00:00:00:00:00:00:00:00:00:ff:f0:00:00:ff:f0 , snr 361 cmts 1, upstrmIdx 0 docsis 02016-10-22 02:02:38,816  WARN [pool-28-thread-1] (CmtsSnmp.java:355) Skipping cmts eq because of invalid data for modem 163845 , eq tap 04:01:08:00:ff:f0:00:00:00:10:00:10:ff:f0:00:00:40:60:00:00:00:20:00:00:ff:f0:00:10:00:10:00:00:ff:f0:ff:f0 , snr 361 cmts 1, upstrmIdx 0 docsis 02016-10-22 02:02:38,831  WARN [pool-28-thread-4] (CmSnmp.java:162) Skipping cm eq because of invalid data for modem 163847 , eq tap 04:01:08:00:00:c9:00:13:fe:c7:00:06:02:a8:00:06:7f:ea:00:00:fd:02:ff:f7:01:7f:00:02:ff:0f:ff:f7:00:9f:ff:fa , tx 3602016-10-22 02:02:38,847  INFO [pool-4-thread-2] (EqTapCollectionManager.java:98) EqTapLogger{upstreamfrequency=36200000, cmts=10.1.1.140/161, modemCount=4, failedModemCount=0, avgTimeForModems=116 ms, maxTimeForModem=374 ms, totalTimeForCMTS=359 ms, totalTimeForSNMP=374 ms, totalTimeForDBUpdates=16 ms, totalTime=390 ms}  The fact that there were only 4 modems helped, simply because if there were even hundreds (or millions) of them, this would be a huge list that repeats every time the modems are polled.  But even with millions, the yellow highlighted parts would still be there.  At first glance, it looks like THERE IS EQ tap data. And there actually is.  But, the key is in those hex values that the modem is returning. Specifically the 04 & 08.  That value 04 is which tap is the main tap, and the 08 is the number of EQ taps that the CMTS is telling the cable modem to use.  04 & 08 are the wrong answers.  That means the modem is only using 8 EQ taps and tap #4 is the main tap.  We want it to be using 24 EQ taps and the main tap should be #8.  If it were using 24 taps and the main tap was #8, that 08 hex code would be 18 and the 04 would be 08.RESOLUTIONBased on this log file, the modems were not returning valid EQ tap data because there were not enough eq taps being used.  In this case, in turns out that it’s a bug with Cisco CMTS when they are set to use ATDMA/TDMA mixed mode for the upstream DOCSIS channels.  In this case, the recommendation is to switch off mixed mode in the CMTS.