On 2 October 2015 at 01:44, Miroslav Suchý <msuchy@xxxxxxxxxx> wrote: > Hi, > this is an issue in Copr: > https://bugzilla.redhat.com/show_bug.cgi?id=1268192 > this happen rarely, but this is not first report. So I should address it somehow. > > Google say: > http://serverfault.com/questions/338439/ssh-sessions-terminate-abruptly-with-message-corrupted-mac-on-input-disconnect > https://ask.openstack.org/en/question/25306/slow-network-speed-between-vm-and-external/ > > I hesitate to turn off checksumming, but switching TCP segmentation offload off gains some improvements. > During several measurements I see gain from 15.2 sec to 14.6 sec (when transferring Fedora ISO). > But I was unable to reproduce the packet corruption. > > The question is - should I disable TCO on Copr machines only, or should I disable it in general VM spinup playbook for > all our VM? I would turn it off on Copr machiens only. If other systems see problems it can be hard to realize "oh that is happening on all boxes" late in the game. If we know we have isolated it to one set of systems it is better to do so. > And this wiki: > https://www.rdoproject.org/Using_GRE_tenant_networks#Offloading > suggest to turn it off for physical hosts too. Not sure why. That is if we are using GRE in the networks. Are we? If we are it does make sense because the GRE in the kernel relies on dealing with an 'uncorrupted' packet which offloading does. > I welcome your comments > > Mirek > > > > > > -------- Přeposlaná zpráva -------- > Předmět: [Bug 1268192] New: Rsync fails with "Corrupted MAC on input. Disconnecting: Packet corrupt" > Datum: Fri, 02 Oct 2015 05:27:49 +0000 > Od: bugzilla@xxxxxxxxxx > Komu: msuchy@xxxxxxxxxx > > https://bugzilla.redhat.com/show_bug.cgi?id=1268192 > > Bug ID: 1268192 > Summary: Rsync fails with "Corrupted MAC on input. > Disconnecting: Packet corrupt" > Product: Copr > Component: backend > Assignee: msuchy@xxxxxxxxxx > Reporter: redhatbugzilla@xxxxxxxxxx > > > > Description of problem: > copr builds are building successfully, but the final rsync fails with an error > message. > > Version-Release number of selected component (if applicable): > > > How reproducible: > Random, occurred twice on Fedora Rawhide, once on EPEL 7, but I only did 5 > builds. > > Steps to Reproduce: > 1. Start a copr build, possibly only on EPEL7/Fedora Rawhide > 2. Wait > 3. Build might be marked as failed despite rpm packages being in the fold > afterwards. > > Actual results: > Some copr builds fail inexplicably in the middle of an rsync job. > > Expected results: > Rsync is successful > > Additional info: > Affected builds: > https://copr-be.cloud.fedoraproject.org/results/kyl191/nginx-pagespeed/fedora-rawhide-x86_64/00122195-nginx-pagespeed/build-00122195.rsync.log > > https://copr-be.cloud.fedoraproject.org/results/kyl191/nginx-pagespeed/epel-7-x86_64/00122218-nginx-pagespeed/build-00122218.rsync.log > > https://copr-be.cloud.fedoraproject.org/results/kyl191/nginx-pagespeed/fedora-rawhide-i386/00122219-nginx-pagespeed/build-00122219.rsync.log > > -- > You are receiving this mail because: > You are the assignee for the bug. > > _______________________________________________ > infrastructure mailing list > infrastructure@xxxxxxxxxxxxxxxxxxxxxxx > http://lists.fedoraproject.org/postorius/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx -- Stephen J Smoogen. _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/postorius/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
