The fault that only appears at 11 in the morning is not mocking you. Load changes physics: more traffic means more collisions on a mismatched link, more errors on a marginal pair, more heat in the switch and more watts drawn from its PoE budget. Idle-time tests clear all four suspects wrongly.
Notice when the complaint arrives. The user in the video lost Tally after a few minutes of actual work, not at login. Under-load loss is a family: a duplex mismatch that only collides when both ends talk at once; a cable pair that holds at light traffic and errors at full gigabit rate; a small switch cooking in a closed cabinet and flapping ports; IP phones and cameras browning out when the PoE budget runs dry at peak draw. Each suspect has a test, and every test involves making the load happen on purpose.
Example only: loss that keeps office hours is telling you the trigger is traffic, temperature or power draw - all three rise and fall with the working day.
The half-duplex end of a mismatched link only collides when it tries to talk while the other end is talking - probability that scales with traffic. At idle, a mismatched link can run for hours clean. Under a backup or a big print run it sheds packets in bursts and the error counters on the switch port climb with runts and CRC errors. If loss tracks load, audit Speed and Duplex on both ends before touching cable - it is the only suspect that is free to fix.
A damaged pair may carry light gigabit traffic and still produce errors when the link is driven hard - sustained full-rate transfers push signalling to its margins. Test honestly: a continuous ping alone is light traffic. Run the ping during a large file copy to the same machine. Loss that exists only with the copy running points at the pair, the terminations or the port - swap test the chain while loaded, not after it cools down.
Small switches live in ceiling voids, locked cabinets and stacks of warm hardware. Overheated switches reboot, drop links for seconds, or throttle - and cool down overnight to pass the morning test. If drops cluster on hot afternoons or in one cabinet, put a hand on the switch: too hot to hold comfortably is a diagnosis. Give it air, unstack it, and log whether the drops follow the temperature. Fanless switches in enclosed racks are the repeat offenders.
A PoE switch has a total watt budget shared by every phone, camera and access point. Devices draw their peak when screens light, heaters switch on in cameras at night, or a floor of phones reboots after a power blip. When the budget is exceeded, the switch sheds or browns out ports - devices reboot, links flap, pings drop in waves that look exactly like a network fault. Read the switch PoE page: total budget versus actual draw, and per-port consumption. The cure is arithmetic - a bigger budget, fewer devices per switch, or local power for the hungry ones.
See the video case - the Tally user whose fault kept office hours, and the setting that explained it once someone measured during the failure.
Watch Full VideoBecause the usual causes scale with load. A duplex mismatch collides only when both ends transmit together, a marginal cable pair errors at full traffic rates, switches overheat as they work, and PoE budgets run out at peak draw. An idle network is an easy network - test under the load that triggers the complaint.
Run a continuous ping to the gateway and the affected server while generating real traffic - copy a large file to the machine, start the backup, print the big job. Compare loss at idle versus under load, and check the switch port error counters before and after. Loss that appears only under load names its family.
Yes. When the PoE budget is exceeded, phones, cameras and access points reboot or their links flap, which reads exactly like packet loss from a desk. Check the switch PoE status: total budget against drawn watts, and whether drops match device peak times such as camera heaters at night.