Also, performing a git clone or git pull is significantly different than downloading a tarball. Someone correct me if I am wrong but Git essentially has to reconstruct the files from its internal data structures. If you clone a large repository with a lot of history it will take longer than a smaller repository with less history.
> On Feb 22, 2017, at 3:47 PM, Aaron C. de Bruyn via NANOG <nanog@nanog.org> > wrote: > > If they are using 'git pull', or 'git push' for example, they may be > accessing the data via HTTPS or SSH. > > Can your user do a 'git remote -v' and see if they are connecting via > HTTPS or SSH to assist you with troubleshooting? > > Then see if it's something specific to one or the other and if it's > specific to github or all sites. > > -A > > On Wed, Feb 22, 2017 at 3:40 PM, Bob Evans <b...@fiberinternetcenter.com> > wrote: >> Hello NANOGers, >> >> I have one customer that claims that 2 out of 17 downloads using the git >> command on github's service are slow and poor on our network when compared >> to others. >> >> However, when not using the git command , but using a simple web page link >> to a large zipped file from github, its always nice and fast. Using the >> git command 8% of the time being slow is unacceptable. Github just doesnt >> responds lethargically at best. BTW, have you seen how many hex digits a >> github ticket number is ? >> >> Of course Github says try a different ISP...Customer tries to tell me >> comcast is better ! What ! I dont believe it. No help from Github NOC - we >> have asked and asked... And we peer with Github and for some reason they >> do not transmit the Prefixes of the IP range that the customer uses for >> the git command. github.com resolve IPv4 is not in the prefix list. So >> the exit is transits. >> >> I need more clues. Is it the resources the git command uses when checking >> files for dates etc ? >> >> Thank You >> Bob Evans >> CTO >> >> >> >> >> >>