Então, Galactus: trocar os switches é sempre uma boa consideração, mas investir num switch de boa qualidade só pra resolver essa lentidão é pedir pra se decepcionar, pq muito provavelmente ele vai trocar o switch e vai continuar tudo lento, pq só depois de muito tempo vai perceber que o motivo da lentidão é outro.
Eu tentaria, nesse momento, entender que aplicações estão rodando em cada uma das máquinas, e principalmente, acompanhar os aplicativos rodando no servidor. Há ainda algumas coisas nesse servidor que não foram informadas, por exemplo, quais são os discos que ele usa, como está o uso da memória, e, principalmente, como o aplicativo rodando no servidor depende desses parâmetros.
Por exemplo, o servidor tem relativamente pouca memória, em se tratando de um servidor de rede. Pode ser que ele esteja tendo que fazer swap. Pode ser também que o sistema de discos do servidor esteja sendo sobrecarregado, e nesse ponto, novamente, há combinações boas e ruins de SGBD (e a gente não sabe se há um) com sistemas de arquivos (ext2/3/4, reiserfs, xfs, ntfs, etc).
Voltando às estações de trabalho... são vários PDVs com Slackware (Deus, quem ainda Slack em produção??? Ou, quem alguma vez usou Slack em produção???), OK, controlado, mas algumas estações Windows... mas ele não disse que uso é feito dessas estações Windows. São PDVs? Ou máquinas de uso geral? Se são de uso geral, já verificou se os usuários delas não estão rodando aplicações que possam estar interferindo no resto da rede? Por incrível que pareça, aplicações simples como um cliente Dropbox podem inundar sua rede local com broadcasts que podem terminar de derrubar uma rede mal projetada.
Enfim: tem muita, muita coisa a ser checada antes de partir pra fazer análise de pacotes. Isso só deveria ser feito em último caso, e de forma bem mais refinada do que amostrando toda a rede.