oles@ovh.net
10-26-2008, 10:50 PM
Hello,
Here is the current status of deliveries (2008-10-26 23h00).
Real Private Server
- RPS 1 12H delay (The oldest order paid and not deployed is dated2008-10-26 16:00:14)
- RPS 2 OK -> 1 hour
- RPS 3 OK -> 1 hour
Servers to experiment and to play with:
- Kimsufi L OK -> 1 hour
- Kimsufi XL 12H delay (The oldest order paid and not deployed is dated 2008-10-26 05:01:41)
- Kimsufi 2XL OK -> 1 hour
- Kimsufi 3XL OK -> 1 hour
- Kimsufi 4XL OK -> 1 hour
Pro, business and critical servers:
- miniSP OK -> 1 hour
- SP bestof OK -> 1 hour
- SP Max fr,es OK -> 1 hour
- SP Max de OK -> 1 hour
- SP Max uk,pl OK -> 1 hour
- EG Bestof 12H delay (The oldest order paid and not deployed is dated 2008-10-26 05:12:04)
- EG Max OK -> 1 hour
- EG Large OK -> 1 hour
- EG SSD OK -> 1 hour
- MG Bestof OK -> 1 hour
- MG Max OK -> 1 hour
- MG Large OK -> 1 hour
- MG SSD OK -> 1 hour
- MG X Large OK -> 1 hour
- miniHG OK -> 1 hour
- HG Bestof 3 days delay (The oldest order paid and not deployed is dated 2008-10-23 20:02:10)
- HG BiTurbo 3 days delay (The oldest order paid and not deployed is dated 2008-10-23 17:53:03)
- HG Large 7 days delay (The oldest order paid and not deployed is dated 2008-10-16 21:01:05)
Deliveries of RPS were not very regular this week. We experiencing a violent growth of orders for 2 weeks and we are still struggling to know how many new RPS have to be manufactured per week. Also, the current system for delivering RPS's is not set up to deliver more than 100 RPS / day, because of "no parallelism" of operations on the storage infrastructure. We are therefore changing working methods and in a few days we should finalize the industrialization of process for the RPS. The aim is not to display the number of RPS available but to always have the stock necessary to deliver to all customers, regardless the quantity in 1 hour. This is the contract.
Kimsufi and PRO are deployed without any problem, except for HG. As already announced, we expect the launch of a new range of HG 2009 later this week, maximum 10 days and production has been shifted already to the new servers available in 1 hour. We are working on the site and the engine options. Indeed, we want to propose to you an extremely powerful server, very stable and fully personnalisable. Within 10 days max, we will have the answer as to whether we are going in the right direction.
This week, we completed 90% of the Ovh European backbone. We are on Espanix in Madrid with 2x10G on MIX in Milan with 1x10G on VIX in Vienna with 1x10G on NIX in Prague with 1x10G and we are establishing the first peering with other networks present on these peering points and who wish to exchange traffic with Ovh. This week we start the TIX and SwissIX in Zurick and then it will be the turn of Warsaw (a little complicated but we'll manage). You can see our network in real-time on the weathermap http://weathermap.ovh.net/europe. It is a backbone based on 10G. For those who like to get worked up, there is a full version with all input / output links of Ovh: http://weathermap.ovh.net/backbone. Today, we have balanced traffic between all cities so that the network is optimized. The traffic between Roubaix and Milan will now go through Roubaix-Paris-Frankfurt-Zurich-Milan instead of Roubaix-Paris-Madrid-Milan and finally a gainof 30ms. Also, traffic from Vienna to Paris, through Prague-Frankfurt rather than by Milan-Zurick-Frankfurt.
We still have some problems to be solved on the backbone:
- http://translate.google.com/translate?u=http%3A%2F%2Ftravaux.ovh.com%2F%3Fdo%3 Ddetails%26id%3D2547&hl=en&ie=UTF-8&sl=fr&tl=en
We will add a 10G between the router and the switch that manages the Decix interconnections. The xenpack arrives tomorrow in Frankfurt and will be established in the same time.
- http://translate.google.com/translate?u=http%3A%2F%2Ftravaux.ovh.com%2F%3Fdo%3 Ddetails%26id%3D2534&hl=en&ie=UTF-8&sl=fr&tl=en
We have an odd problem on Linx 224. The flow of some customers to some traffic who we trade traffic on Linx 224 with, is not at full speed. According to tests of some customers, we have isolated Linx 224, but according to Linx there is no problem of Linx internal saturation. We'll change all garters fiber optic on all our infrastructure across London. Even if there is no packet loss, there is something somewhere. We must begin somewhere. http://weathermap.ovh.net/london
- http://translate.google.com/translate?u=http%3A%2F%2Ftravaux.ovh.com%2F%3Fdo%3 Ddetails%26id%3D2492&hl=en&ie=UTF-8&sl=fr&tl=en
a switch should be set up in Brussels / Interxion then connected 10G between the router of Brussels and Roubaix to ensure better redundancy. It should be realized this week.
With the arrival of this network, we are very close to start with ChtiX.eu with VLAN offers between all sites where we are present and all peering points where we operate. Thus, having 100Mbps between Paris and Vienna it is 100euro per month! Also, transit offers 100Mbps = 100euro / month in full BGP. A unique offer available throughout Europe.
Some PL and UK customers have reported a bug on the internal bandwidth on our network. Part of this problem is solved, but not all. We have actually a lot of different network equipment and we must adjust the setup for each element, while being sure it has the same effect. We have realised that depending on the equipment, the settings should be different to acheive the same end result. That is the problem. We hope that we will fix all these problems this week (it takes a long time to test all to see the results in real time and on the MRTG / DRP graphs). http://translate.google.com/translate?u=http%3A%2F%2Ftravaux.ovh.com%2F%3Fdo%3 Ddetails%26id%3D2495&hl=en&ie=UTF-8&sl=fr&tl=en.
With the arrival of the East / South-East backbone, traffic via Frankfurt will increase in the coming weeks. Indeed, Prague, Vienna, Zurick and Milan go through Frankfurt. We will therefore start the work of creating the backbone at 100Gbps between Brussels and Frankfurt. This work will take between 4 and 6 months. We should therefore enjoy from February / March.
All these approaches and investment in the network have a specific purpose: to improve access for all European visitors to our infrastructure. We have to find a way that for example a CZ visitor can consult your sites more quickly and can exchange traffic with your sites more quickly. The aim is not to build the biggest network in the world, but to go to visitors closer to where they live and carry on our network all the traffic. In this way only, we will be able to guarantee the time access and the flow, knowing that despite 100km will generate 1ms access time and more so we will not have to create a black hole in the cosmos to get packets to Ovh. Looking at the results of this strategy we can also wonder about the meaning of all these approaches. Take for Example: a peering established 30 minutes ago with a large network in CZ. We have had the peering over AMSIX (Amsterdam) and we have now NIX (Prague). The result of a gain of 4ms. 4ms ... What is 4ms in our lives?
64 bytes from 195.113.144.244: icmp_seq=6 ttl=58 time=21.2 ms
64 bytes from 195.113.144.244: icmp_seq=7 ttl=58 time=21.1 ms
64 bytes from 195.113.144.244: icmp_seq=8 ttl=58 time=21.1 ms
64 bytes from 195.113.144.244: icmp_seq=9 ttl=58 time=21.1 ms
64 bytes from 195.113.144.244: icmp_seq=10 ttl=58 time=21.1 ms
64 bytes from 195.113.144.244: icmp_seq=11 ttl=58 time=17.6 ms
64 bytes from 195.113.144.244: icmp_seq=12 ttl=58 time=17.5 ms
64 bytes from 195.113.144.244: icmp_seq=13 ttl=58 time=17.7 ms
64 bytes from 195.113.144.244: icmp_seq=14 ttl=58 time=17.6 ms
Looking at the results of this strategy we can also wonder about the meaning of all these approaches. Take for Example: a peering established 30 minutes ago with a large network in CZ. We have had the peering over AMSIX (Amsterdam) and we have now NIX (Prague). The result of a gain of 4ms. 4ms ... What is 4ms in our lives?
Regards,
Octave
Here is the current status of deliveries (2008-10-26 23h00).
Real Private Server
- RPS 1 12H delay (The oldest order paid and not deployed is dated2008-10-26 16:00:14)
- RPS 2 OK -> 1 hour
- RPS 3 OK -> 1 hour
Servers to experiment and to play with:
- Kimsufi L OK -> 1 hour
- Kimsufi XL 12H delay (The oldest order paid and not deployed is dated 2008-10-26 05:01:41)
- Kimsufi 2XL OK -> 1 hour
- Kimsufi 3XL OK -> 1 hour
- Kimsufi 4XL OK -> 1 hour
Pro, business and critical servers:
- miniSP OK -> 1 hour
- SP bestof OK -> 1 hour
- SP Max fr,es OK -> 1 hour
- SP Max de OK -> 1 hour
- SP Max uk,pl OK -> 1 hour
- EG Bestof 12H delay (The oldest order paid and not deployed is dated 2008-10-26 05:12:04)
- EG Max OK -> 1 hour
- EG Large OK -> 1 hour
- EG SSD OK -> 1 hour
- MG Bestof OK -> 1 hour
- MG Max OK -> 1 hour
- MG Large OK -> 1 hour
- MG SSD OK -> 1 hour
- MG X Large OK -> 1 hour
- miniHG OK -> 1 hour
- HG Bestof 3 days delay (The oldest order paid and not deployed is dated 2008-10-23 20:02:10)
- HG BiTurbo 3 days delay (The oldest order paid and not deployed is dated 2008-10-23 17:53:03)
- HG Large 7 days delay (The oldest order paid and not deployed is dated 2008-10-16 21:01:05)
Deliveries of RPS were not very regular this week. We experiencing a violent growth of orders for 2 weeks and we are still struggling to know how many new RPS have to be manufactured per week. Also, the current system for delivering RPS's is not set up to deliver more than 100 RPS / day, because of "no parallelism" of operations on the storage infrastructure. We are therefore changing working methods and in a few days we should finalize the industrialization of process for the RPS. The aim is not to display the number of RPS available but to always have the stock necessary to deliver to all customers, regardless the quantity in 1 hour. This is the contract.
Kimsufi and PRO are deployed without any problem, except for HG. As already announced, we expect the launch of a new range of HG 2009 later this week, maximum 10 days and production has been shifted already to the new servers available in 1 hour. We are working on the site and the engine options. Indeed, we want to propose to you an extremely powerful server, very stable and fully personnalisable. Within 10 days max, we will have the answer as to whether we are going in the right direction.
This week, we completed 90% of the Ovh European backbone. We are on Espanix in Madrid with 2x10G on MIX in Milan with 1x10G on VIX in Vienna with 1x10G on NIX in Prague with 1x10G and we are establishing the first peering with other networks present on these peering points and who wish to exchange traffic with Ovh. This week we start the TIX and SwissIX in Zurick and then it will be the turn of Warsaw (a little complicated but we'll manage). You can see our network in real-time on the weathermap http://weathermap.ovh.net/europe. It is a backbone based on 10G. For those who like to get worked up, there is a full version with all input / output links of Ovh: http://weathermap.ovh.net/backbone. Today, we have balanced traffic between all cities so that the network is optimized. The traffic between Roubaix and Milan will now go through Roubaix-Paris-Frankfurt-Zurich-Milan instead of Roubaix-Paris-Madrid-Milan and finally a gainof 30ms. Also, traffic from Vienna to Paris, through Prague-Frankfurt rather than by Milan-Zurick-Frankfurt.
We still have some problems to be solved on the backbone:
- http://translate.google.com/translate?u=http%3A%2F%2Ftravaux.ovh.com%2F%3Fdo%3 Ddetails%26id%3D2547&hl=en&ie=UTF-8&sl=fr&tl=en
We will add a 10G between the router and the switch that manages the Decix interconnections. The xenpack arrives tomorrow in Frankfurt and will be established in the same time.
- http://translate.google.com/translate?u=http%3A%2F%2Ftravaux.ovh.com%2F%3Fdo%3 Ddetails%26id%3D2534&hl=en&ie=UTF-8&sl=fr&tl=en
We have an odd problem on Linx 224. The flow of some customers to some traffic who we trade traffic on Linx 224 with, is not at full speed. According to tests of some customers, we have isolated Linx 224, but according to Linx there is no problem of Linx internal saturation. We'll change all garters fiber optic on all our infrastructure across London. Even if there is no packet loss, there is something somewhere. We must begin somewhere. http://weathermap.ovh.net/london
- http://translate.google.com/translate?u=http%3A%2F%2Ftravaux.ovh.com%2F%3Fdo%3 Ddetails%26id%3D2492&hl=en&ie=UTF-8&sl=fr&tl=en
a switch should be set up in Brussels / Interxion then connected 10G between the router of Brussels and Roubaix to ensure better redundancy. It should be realized this week.
With the arrival of this network, we are very close to start with ChtiX.eu with VLAN offers between all sites where we are present and all peering points where we operate. Thus, having 100Mbps between Paris and Vienna it is 100euro per month! Also, transit offers 100Mbps = 100euro / month in full BGP. A unique offer available throughout Europe.
Some PL and UK customers have reported a bug on the internal bandwidth on our network. Part of this problem is solved, but not all. We have actually a lot of different network equipment and we must adjust the setup for each element, while being sure it has the same effect. We have realised that depending on the equipment, the settings should be different to acheive the same end result. That is the problem. We hope that we will fix all these problems this week (it takes a long time to test all to see the results in real time and on the MRTG / DRP graphs). http://translate.google.com/translate?u=http%3A%2F%2Ftravaux.ovh.com%2F%3Fdo%3 Ddetails%26id%3D2495&hl=en&ie=UTF-8&sl=fr&tl=en.
With the arrival of the East / South-East backbone, traffic via Frankfurt will increase in the coming weeks. Indeed, Prague, Vienna, Zurick and Milan go through Frankfurt. We will therefore start the work of creating the backbone at 100Gbps between Brussels and Frankfurt. This work will take between 4 and 6 months. We should therefore enjoy from February / March.
All these approaches and investment in the network have a specific purpose: to improve access for all European visitors to our infrastructure. We have to find a way that for example a CZ visitor can consult your sites more quickly and can exchange traffic with your sites more quickly. The aim is not to build the biggest network in the world, but to go to visitors closer to where they live and carry on our network all the traffic. In this way only, we will be able to guarantee the time access and the flow, knowing that despite 100km will generate 1ms access time and more so we will not have to create a black hole in the cosmos to get packets to Ovh. Looking at the results of this strategy we can also wonder about the meaning of all these approaches. Take for Example: a peering established 30 minutes ago with a large network in CZ. We have had the peering over AMSIX (Amsterdam) and we have now NIX (Prague). The result of a gain of 4ms. 4ms ... What is 4ms in our lives?
64 bytes from 195.113.144.244: icmp_seq=6 ttl=58 time=21.2 ms
64 bytes from 195.113.144.244: icmp_seq=7 ttl=58 time=21.1 ms
64 bytes from 195.113.144.244: icmp_seq=8 ttl=58 time=21.1 ms
64 bytes from 195.113.144.244: icmp_seq=9 ttl=58 time=21.1 ms
64 bytes from 195.113.144.244: icmp_seq=10 ttl=58 time=21.1 ms
64 bytes from 195.113.144.244: icmp_seq=11 ttl=58 time=17.6 ms
64 bytes from 195.113.144.244: icmp_seq=12 ttl=58 time=17.5 ms
64 bytes from 195.113.144.244: icmp_seq=13 ttl=58 time=17.7 ms
64 bytes from 195.113.144.244: icmp_seq=14 ttl=58 time=17.6 ms
Looking at the results of this strategy we can also wonder about the meaning of all these approaches. Take for Example: a peering established 30 minutes ago with a large network in CZ. We have had the peering over AMSIX (Amsterdam) and we have now NIX (Prague). The result of a gain of 4ms. 4ms ... What is 4ms in our lives?
Regards,
Octave