CRC checks of downloads fail really often

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

CRC checks of downloads fail really often

Guillermo Polito
Hi,

In the travis jobs of many projects (pillar, ossubprocess), I see often this failure:

image.eqoxhz/Pharo7.0-32bit-b648168.image bad CRC 298b4e64 (should be 85ee6276)

This is happening all the time for large builds, generally in 1 out of 4 jobs:


Of course restarting the job (to retry the download) solves the problem eventually.

Is this because of the inria infrastructure working funny? 


--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: CRC checks of downloads fail really often

NorbertHartl
Yes, this drives me crazy. You cannot do much or invite people to use it because the download does not work. Sometimes it is really ridiculous.

Norbert

Am 09.11.2017 um 10:28 schrieb Guillermo Polito <[hidden email]>:

Hi,

In the travis jobs of many projects (pillar, ossubprocess), I see often this failure:

image.eqoxhz/Pharo7.0-32bit-b648168.image bad CRC 298b4e64 (should be 85ee6276)

This is happening all the time for large builds, generally in 1 out of 4 jobs:


Of course restarting the job (to retry the download) solves the problem eventually.

Is this because of the inria infrastructure working funny? 


--
   
Guille Polito
Research Engineer


Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research - http://www.cnrs.fr

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: CRC checks of downloads fail really often

Marcus Denker-4
As a first step of a new instrastructure I have added a mirror:


update is not yet working for files that keep the same name yet change content.
This will be added I hope tomorrow.

Marcus

On 9 Nov 2017, at 18:33, Norbert Hartl <[hidden email]> wrote:

Yes, this drives me crazy. You cannot do much or invite people to use it because the download does not work. Sometimes it is really ridiculous.

Norbert

Am 09.11.2017 um 10:28 schrieb Guillermo Polito <[hidden email]>:

Hi,

In the travis jobs of many projects (pillar, ossubprocess), I see often this failure:

image.eqoxhz/Pharo7.0-32bit-b648168.image bad CRC 298b4e64 (should be 85ee6276)

This is happening all the time for large builds, generally in 1 out of 4 jobs:


Of course restarting the job (to retry the download) solves the problem eventually.

Is this because of the inria infrastructure working funny? 


--
   
Guille Polito
Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research - http://www.cnrs.fr

Phone: +33 06 52 70 66 13


Reply | Threaded
Open this post in threaded view
|

Re: CRC checks of downloads fail really often

Stephane Ducasse-3
Thanks Marcus. For 200 Euros I can even offering to the community. 
I'm sad that our inria infrastructure is not at the right level. 

Stef

On Thu, Nov 9, 2017 at 7:18 PM, Marcus Denker <[hidden email]> wrote:
As a first step of a new instrastructure I have added a mirror:


update is not yet working for files that keep the same name yet change content.
This will be added I hope tomorrow.

Marcus

On 9 Nov 2017, at 18:33, Norbert Hartl <[hidden email]> wrote:

Yes, this drives me crazy. You cannot do much or invite people to use it because the download does not work. Sometimes it is really ridiculous.

Norbert

Am 09.11.2017 um 10:28 schrieb Guillermo Polito <[hidden email]>:

Hi,

In the travis jobs of many projects (pillar, ossubprocess), I see often this failure:

image.eqoxhz/Pharo7.0-32bit-b648168.image bad CRC 298b4e64 (should be 85ee6276)

This is happening all the time for large builds, generally in 1 out of 4 jobs:


Of course restarting the job (to retry the download) solves the problem eventually.

Is this because of the inria infrastructure working funny? 


--
   
Guille Polito
Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research - http://www.cnrs.fr

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13



Reply | Threaded
Open this post in threaded view
|

Re: CRC checks of downloads fail really often

Marcus Denker-4
We will see how much it costs… price is:

$0.049 for GB Traffic from US & EUROPE
$0.125 / GB From ASIA & PACIFIC
 $0.185 / GB From LATIN AMERICA

(one could turn off the more expensive ones).

But the idea is to set this up as an intermediate solution and then work on the main
infrastructure (that is, replace files.pharo.org, with either a server or maybe just amazon
s3 of the cost with the CDN in front is OK).


        Marcus

> On 9 Nov 2017, at 21:08, Stephane Ducasse <[hidden email]> wrote:
>
> Thanks Marcus. For 200 Euros I can even offering to the community.
> I'm sad that our inria infrastructure is not at the right level.
>
> Stef
>
> On Thu, Nov 9, 2017 at 7:18 PM, Marcus Denker <[hidden email]> wrote:
> As a first step of a new instrastructure I have added a mirror:
>
> https://mirror.pharo.org
>
> update is not yet working for files that keep the same name yet change content.
> This will be added I hope tomorrow.
>
> Marcus
>
>> On 9 Nov 2017, at 18:33, Norbert Hartl <[hidden email]> wrote:
>>
>> Yes, this drives me crazy. You cannot do much or invite people to use it because the download does not work. Sometimes it is really ridiculous.
>>
>> Norbert
>>
>>> Am 09.11.2017 um 10:28 schrieb Guillermo Polito <[hidden email]>:
>>>
>>> Hi,
>>>
>>> In the travis jobs of many projects (pillar, ossubprocess), I see often this failure:
>>>
>>> image.eqoxhz/Pharo7.0-32bit-b648168.image bad CRC 298b4e64 (should be 85ee6276)
>>>
>>> This is happening all the time for large builds, generally in 1 out of 4 jobs:
>>>
>>> https://travis-ci.org/marianopeck/OSSubprocess/builds/299269491
>>> https://travis-ci.org/pillar-markup/pillar/jobs/298538119
>>>
>>> Of course restarting the job (to retry the download) solves the problem eventually.
>>>
>>> Is this because of the inria infrastructure working funny?
>>>
>>>
>>> --
>>>    
>>> Guille Polito
>>> Research Engineer
>>>
>>> Centre de Recherche en Informatique, Signal et Automatique de Lille
>>> CRIStAL - UMR 9189
>>> French National Center for Scientific Research - http://www.cnrs.fr
>>>
>>> Web: http://guillep.github.io
>>> Phone: +33 06 52 70 66 13
>>
>
>