Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Advertise on LowEndTalk.com
PHP-Friends
New on LowEndTalk? Please read our 'Community Rules' by clicking on it in the right menu!

PHP-Friends

Can anyone tell me if php-friends provision outside of normal business hours?

App Development | Eingress Ltd

Comments

  • fendixfendix Member

    According to my experience: yes.

    Thanked by 1eingress
  • eingresseingress Member

    Thanks @fendix, much appreciated.

    App Development | Eingress Ltd

  • G4SHIG4SHI Member

    Yes , they usually work in outside normal hours , Tim maybe will provision your order :) he is the best support ever and super guy :) Vouch for php-friends

    Thanked by 2PHP_Friends eingress
  • PHP_FriendsPHP_Friends Member, Provider

    Hi,

    yes, we do. We guarantee 12 hours after payment but that's only to cover edge cases (for example orders at Friday or Saturday night when no one from us is awake anymore and no one is in the office at 9:00 next day). In these edge cases it can - in theory - take up to 12 hours, but as verifying and provisioning orders is - if all data is correct - a thing of a few seconds, we keep an eye on orders out of our business hours. As long as at least one of us is awake and at his desk, it's usually a matter of minutes or a few hours.

    Best Regards,
    Tim

    Thanked by 2Wolf eingress

    AMD EPYC NVMe servers located at maincubes FRA01: https://php-friends.de/vserver-ssd

  • eingresseingress Member

    Thanks for the repsonses everyone.

    For everyone's information, provisioning took about 40 minutes after invoice was paid.

    :)

    Thanked by 1PHP_Friends

    App Development | Eingress Ltd

  • NeoonNeoon Member

    Well, since the Location has been switched, a lot of traffic seems to get dumped of via free peering at CDN77.

    MTR to a Server in dallas has 24 hops, and goes via Prague.
    Not only Dallas, also Swiss goes over Prague.

    A lot of stuff goes over Prague since the location switched, instead of direct from Frankfurt.... sad.

    Thanked by 1webcraft
  • debaserdebaser Member

    Provide us an example please? I can’t reproduce this.

    Thanked by 2Falzo boernd
  • fendixfendix Member

    Short statement @PHP_Friends ?

  • NeoonNeoon Member
    edited July 11

    @debaser said:
    Provide us an example please? I can’t reproduce this.

    Everything, as it seems.
    I guess then Avoro is to blame not php-friends, my fault.

    Avoro used php-friends network, but I guess since then, a lot of stuff changed... to he worst.

    edit: mtr suggest its still php-friends network to blame.

  • vyas11vyas11 Member
    edited July 11

    @Neoon said:

    @debaser said:
    Provide us an example please? I can’t reproduce this.

    Everything, as it seems.
    I guess then Avoro is to blame not php-friends, my fault.

    Avoro used php-friends network, but I guess since then, a lot of stuff changed... to he worst.

    edit: mtr suggest its still php-friends network to blame.

    For Php Friends traceroute shows
    Chennai --> Singapore -->Frankfurt for me.
    I am glad it's data and not an airlines.

    Thanked by 3seriesn vimalware t0m
  • debaserdebaser Member

    @Neoon said:

    @debaser said:
    Provide us an example please? I can’t reproduce this.

    Everything, as it seems.
    I guess then Avoro is to blame not php-friends, my fault.

    Avoro used php-friends network, but I guess since then, a lot of stuff changed... to he worst.

    edit: mtr suggest its still php-friends network to blame.

    As far as I can reproduce it, it’s just providers that use HE.net for transit.

  • PHP_FriendsPHP_Friends Member, Provider

    Please contact our support with MTRs / traceroutes. I don't know what you expect from us when you don't say what exactly we should improve.

    AMD EPYC NVMe servers located at maincubes FRA01: https://php-friends.de/vserver-ssd

  • PHP_FriendsPHP_Friends Member, Provider

    Also I don't know what you mean with free peering at CDN77. We are paying for our traffic :)

    AMD EPYC NVMe servers located at maincubes FRA01: https://php-friends.de/vserver-ssd

  • Probably some old cdn77 reverse host name in the mtr/traceroute output.

    I see that on my liteserver vm too when I test from some sources

    250GB USA RAID6 StorageKVM from €13/yr (no-torrenting, TopProvider)
    (affiliate for 🥰 ) https://clients.inceptionhosting.com/aff.php?aff=401&gid=30

  • PHP_FriendsPHP_Friends Member, Provider

    The "prague" reverse DNS entry of a Telia router, actually located in Frankfurt (FFM), has been corrected.

    The only MTR we received about this "issue" shows - compared with First Colo - an identical route to the destination, besides the fact that it doesn't get routed via DE-CIX but the own internet exchange of CDN77, which doesn't change the latency at all. Sometimes it's even 1 ms better (which is, however, absolutely irrelevant on a path from Germany to the USA).

    AMD EPYC NVMe servers located at maincubes FRA01: https://php-friends.de/vserver-ssd

  • NeoonNeoon Member

    Lemme send the routes where it goes over prag-b3-link.telia.net and back to ffm.

  • Mahfuz_SS_EHLMahfuz_SS_EHL Member, Provider

    Is there any test IP or looking glass of PHP-friends ?

    AlphaSSL Revocation Issue is being investigated.

  • PHP_FriendsPHP_Friends Member, Provider

    @Neoon said:
    Lemme send the routes where it goes over prag-b3-link.telia.net and back to ffm.

    We still have not received a single report which shows a real problem. Why don't you just share the "bad" route instead of talking about it?

    @Mahfuz_SS_EHL said:
    Is there any test IP or looking glass of PHP-friends ?

    You can use 193.41.237.1.

    AMD EPYC NVMe servers located at maincubes FRA01: https://php-friends.de/vserver-ssd

  • PHP_FriendsPHP_Friends Member, Provider

    Latest update from our main carrier:

    11:47 Uhr
    I've written to Telia to update the PTR. Just for your information, the IP with Prague record is Telia side of BGP between us in Frankfurt
    11:47 Uhr
    so it's definitely in Frankfurt, we're not establishing BGP from Frankfurt to Telia in Prague :smiley:

    AMD EPYC NVMe servers located at maincubes FRA01: https://php-friends.de/vserver-ssd

  • PHP_FriendsPHP_Friends Member, Provider

    btw, to make this absolutely transparent and public, this is the hop with the wrong PTR: 213.248.70.153

    We are talking about a latency of 0.8 ms. Everyone can check this with a server located in or near Frankfurt. It is physically impossible that this IP is located in Prague. That would be the best fibre in the world, leaving the speed of light behind :)

    So... This is the "bad route" in our maincubes location (indicated by our own router as first hop, it's our ASN):

    And this is the "good route" via First Colo:

    A lot of trouble for absolutely nothing.

    Thanked by 2vimalware boernd

    AMD EPYC NVMe servers located at maincubes FRA01: https://php-friends.de/vserver-ssd

  • Yes, this sort of goofup happens to me too.

    Sometimes the latency is the only clue I have whether the ip is in the same city especially if it's anycast or something.

    250GB USA RAID6 StorageKVM from €13/yr (no-torrenting, TopProvider)
    (affiliate for 🥰 ) https://clients.inceptionhosting.com/aff.php?aff=401&gid=30

  • debaserdebaser Member
    edited July 14

    @PHP_Friends said:
    it doesn't get routed via DE-CIX but the own internet exchange of CDN77

    I think this is the key to some hypothetical bad routes. My host node is not yet moved to Maincubes, but what I can reproduce is the following:

    For instance from HE.net in Frankfurt:

    core1.fra1.he.net> traceroute 193.41.237.1 source 216.218.252.174 numeric
    Target  193.41.237.1
    Hop Start   1
    Hop End 30
    1   7 ms    7 ms    25 ms   100ge14-1.core1.prg1.he.net (184.105.213.234)
    2   25 ms   39 ms   15 ms   datacamp.peering.cz (91.213.211.28)
    3   29 ms   15 ms   28 ms   cdn77.cr1.synlinq.de (84.17.33.51)
    4   20 ms   45 ms   16 ms   lt0.1.cr3.synlinq.de (45.135.200.15)
    5   16 ms   16 ms   24 ms   mx240-1.maincubes.as58212.net (193.41.237.1)
    

    So this one first travels to Prague, where they peer with CDN77 on Peering.cz and then obviously back to Frankfurt.

    I see the same coming from iFog network in Zürich. Then is Zürich, Frankfurt, Prague, Frankfurt. So not optimal.

    This is caused by CDN77 not peering on DE-CIX, but just on Peering.cz on multiple locations (which Frankfurt is one of). So while CDN77 has a PoP in Frankfurt on Peering.cz, Hurricane Electric only has this in Prague. Hence the detour.

    The same goes for Google, this travels to Prague as well.

    Thanked by 1vimalware
  • NeoonNeoon Member
    edited July 14

    @PHP_Friends said:
    A lot of trouble for absolutely nothing.

    No, that is not the case.

    See, the first traceroutes, I provided, it does indeed confirm, that my eyes where of the table and I did not looked at the latency.

    But I did more as just these and found what I was talking about.
    Before I posted here yesterday, I forwarded everything to avoro.

    You can clearly see, that telia claims Prague is n Frankfurt yes, but where do the additional 5 ms come from?

    Anyway, these PTR records as misleading and are causing confusion.

    Thanked by 1vimalware
  • debaserdebaser Member

    @Neoon said: You can clearly see, that telia claims Prague is n Frankfurt yes, but where do the additional 5 ms come from? looks like the traffic actually went Frankfurt => Prague => Frankfurt.

    I see a round trip time Frankfurt-Zürich of 7ms. This is actually not bad and as expected. As you already confirmed, the router dat indentifies itself as 'prag' is actually in Frankfurt, with 1 ms latency.

    So the only problem would be the Telia router that identifies itself as 'ffm' but has a higher rtt than you'd expect. This could be caused by the return route, however it doesn't really affect the total latency to your server in Zürich.

  • NeoonNeoon Member

    @debaser said:

    @Neoon said: You can clearly see, that telia claims Prague is n Frankfurt yes, but where do the additional 5 ms come from? looks like the traffic actually went Frankfurt => Prague => Frankfurt.

    I see a round trip time Frankfurt-Zürich of 7ms. This is actually not bad and as expected. As you already confirmed, the router dat indentifies itself as 'prag' is actually in Frankfurt, with 1 ms latency.

    So the only problem would be the Telia router that identifies itself as 'ffm' but has a higher rtt than you'd expect. This could be caused by the return route, however it doesn't really affect the total latency to your server in Zürich.

    7ms is ideal, but I saw routes up to 20ms, while the route back was 7 ms, from the same machine. There is some kind of problem since the migration.

    Thanked by 1vimalware
  • debaserdebaser Member

    @Neoon said: 7ms is ideal, but I saw routes up to 20ms, while the route back was 7 ms, from the same machine. There is some kind of problem since the migration.

    Ping is always a round trip time so the latency from machine a to b is always the same as from b to a. Even in the situation where servers are located next to eachother and a to b is a direct route but b to a goes over (for intance) the US, the rtt will be very high either way due to the routing.

    So when the route itself hasn't changed for you, the varying ping is caused by other problems.

    Thanked by 1vimalware
  • NeoonNeoon Member

    @debaser said:

    @Neoon said: 7ms is ideal, but I saw routes up to 20ms, while the route back was 7 ms, from the same machine. There is some kind of problem since the migration.

    Ping is always a round trip time so the latency from machine a to b is always the same as from b to a. Even in the situation where servers are located next to eachother and a to b is a direct route but b to a goes over (for intance) the US, the rtt will be very high either way due to the routing.

    So when the route itself hasn't changed for you, the varying ping is caused by other problems.

    I am aware what RTT means.
    These were just my results between multiple mtr's.

  • debaserdebaser Member
    edited July 14

    The new location probably means that some hiccups need to be ironed out. When I look at routing to my locations, it's actually pretty good and direct but there's some strange routing here and there.

    I think the major issue is that they're relying on just 1 upstream (which is relying on 1 upstream themselves) at the moment.

    I'm sure @PHP_Friends will eventually get this fixed however.

    Thanked by 1vimalware
  • Mahfuz_SS_EHLMahfuz_SS_EHL Member, Provider
    edited July 14

    I used Hetzner & some other hosts in Germany but @PHP_Friends is getting higher latency than them from My Connection.

    To Hetzner:

    Tracing route to hetzner.de [78.47.166.55]
    over a maximum of 30 hops:
    
      1     1 ms     1 ms     3 ms  192.168.0.1
      2     3 ms     2 ms     1 ms  59.153.100.24
      3     4 ms     3 ms     2 ms  172.16.16.89
      4     3 ms     2 ms     2 ms  59.153.100.105
      5     5 ms     5 ms     3 ms  43.224.113.69
      6     5 ms     3 ms     3 ms  103.230.17.112
      7    47 ms    45 ms    45 ms  180.87.39.117
      8   153 ms   224 ms   153 ms  180.87.38.1
      9     *        *        *     Request timed out.
     10   155 ms   154 ms   259 ms  80.231.217.2
     11   268 ms   200 ms     *     80.231.200.78
     12   190 ms   205 ms   196 ms  195.219.87.195
     13   205 ms   179 ms   221 ms  195.219.219.10
     14   222 ms   201 ms   208 ms  213.239.245.34
     15   204 ms   201 ms   201 ms  88.198.247.253
     16   208 ms   201 ms   201 ms  213.239.203.214
     17   203 ms   201 ms   201 ms  78.47.166.55
    

    Typically getting 200ms.

    To Linode:

    Tracing route to speedtest.frankfurt.linode.com [139.162.130.8]
    over a maximum of 30 hops:
    
      1     4 ms     1 ms     1 ms  192.168.0.1
      2     4 ms     2 ms     3 ms  59.153.100.24
      3     3 ms     2 ms     3 ms  172.16.16.89
      4     3 ms     3 ms     2 ms  59.153.100.105
      5     4 ms     4 ms     4 ms  43.224.113.69
      6     6 ms     4 ms     3 ms  103.230.17.112
      7    44 ms    43 ms    45 ms  180.87.39.117
      8   264 ms   200 ms   202 ms  180.87.38.1
      9     *        *        *     Request timed out.
     10   168 ms   201 ms     *     80.231.217.2
     11     *        *        *     Request timed out.
     12   164 ms   183 ms   201 ms  195.219.87.88
     13   202 ms   201 ms   201 ms  195.219.61.48
     14   200 ms   178 ms   229 ms  195.219.61.30
     15   230 ms   201 ms   201 ms  139.162.129.11
     16   199 ms   201 ms   176 ms  139.162.130.8
    

    Same around.

    To @PHP_Friends :

    Tracing route to 193.41.237.1 over a maximum of 30 hops
    
      1     7 ms     6 ms     3 ms  192.168.0.1
      2     2 ms     2 ms     2 ms  59.153.100.24
      3     4 ms     2 ms     2 ms  172.16.16.89
      4     6 ms     3 ms     3 ms  59.153.100.105
      5     5 ms     2 ms     3 ms  43.224.113.69
      6     6 ms     4 ms     6 ms  103.230.17.112
      7    51 ms    52 ms    51 ms  103.230.17.51
      8    53 ms    52 ms    52 ms  103.230.17.30
      9    51 ms    55 ms    53 ms  116.51.26.33
     10   206 ms   287 ms   201 ms  129.250.2.123
     11    54 ms    55 ms    52 ms  129.250.3.83
     12   297 ms   228 ms   201 ms  129.250.7.9
     13   284 ms   201 ms   201 ms  129.250.6.14
     14   314 ms   303 ms   303 ms  213.198.94.170
     15   312 ms   299 ms   208 ms  84.17.33.59
     16   313 ms   304 ms   303 ms  45.135.200.17
     17   305 ms   304 ms   303 ms  193.41.237.1
    

    A 100ms increase than other hosts. What is it so ?

    AlphaSSL Revocation Issue is being investigated.

  • debaserdebaser Member

    @Mahfuz_SS_EHL said: A 100ms increase than other hosts. What is it so ?

    Only thing I can spot is that the reverse route is different from your route. It goes through Hurricane Electric, with a little detour but not up to the point that you'd gain 100ms.

    Thanked by 1sgheghele
  • PHP_FriendsPHP_Friends Member, Provider

    @debaser said:
    The new location probably means that some hiccups need to be iround out.
    [...]
    I'm sure @PHP_Friends will eventually get this fixed however.

    This is correct.

    I think the major issue is that they're relying on just 1 upstream (which is relying on 1 upstream themselves) at the moment.

    This is not (really) correct, but we are not done yet with the secondary carrier. For safety reasons we do it prefix after prefix. More peerings / carriers will follow.

    Generally we are thankful for every single feedback, but we will always need both directions delivered as support ticket. We can't do network / routing support via LET, esspecially as this is absolutely not my job and my colleagues don't have access to my LET account. I have basic Juniper knowledge but I'm not operating our network :sweat_smile:

    Best Regards,
    Tim

    Thanked by 1vimalware

    AMD EPYC NVMe servers located at maincubes FRA01: https://php-friends.de/vserver-ssd

  • Mahfuz_SS_EHLMahfuz_SS_EHL Member, Provider

    @debaser said:

    @Mahfuz_SS_EHL said: A 100ms increase than other hosts. What is it so ?

    Only thing I can spot is that the reverse route is different from your route. It goes through Hurricane Electric, with a little detour but not up to the point that you'd gain 100ms.

    But, all other hosts in Germany remain between 200-230 ms from BD. @PHP_Friends is constantly getting 300ms+ which we get to US from Bangladesh.

    AlphaSSL Revocation Issue is being investigated.

  • serv_eeserv_ee Member

    @PHP_Friends said:

    @debaser said:
    The new location probably means that some hiccups need to be iround out.
    [...]
    I'm sure @PHP_Friends will eventually get this fixed however.

    This is correct.

    I think the major issue is that they're relying on just 1 upstream (which is relying on 1 upstream themselves) at the moment.

    This is not (really) correct, but we are not done yet with the secondary carrier. For safety reasons we do it prefix after prefix. More peerings / carriers will follow.

    Generally we are thankful for every single feedback, but we will always need both directions delivered as support ticket. We can't do network / routing support via LET, esspecially as this is absolutely not my job and my colleagues don't have access to my LET account. I have basic Juniper knowledge but I'm not operating our network :sweat_smile:

    Best Regards,
    Tim

    What do you mean LET is not your support desk? I thought it's every hosting companies priority /s

    Thanked by 1PHP_Friends

    I swear to drunk Im not god

  • debaserdebaser Member
    edited July 14

    @PHP_Friends said: Generally we are thankful for every single feedback, but we will always need both directions delivered as support ticket. We can't do network / routing support via LET, esspecially as this is absolutely not my job and my colleagues don't have access to my LET account. I have basic Juniper knowledge but I'm not operating our network

    I understand that, I'd very much like to help but as I said: my host node is still in First Root, so all routes I've done is from the Avoro looking glass and to your gateway ip.

    More to provide some background than anything else, to be honest.

    I think @Neoon is actually an Avoro customer.

  • NeoonNeoon Member

    @debaser said:

    @PHP_Friends said: Generally we are thankful for every single feedback, but we will always need both directions delivered as support ticket. We can't do network / routing support via LET, esspecially as this is absolutely not my job and my colleagues don't have access to my LET account. I have basic Juniper knowledge but I'm not operating our network

    I understand that, I'd very much like to help but as I said: my host node is still in First Root, so all routes I've done is from the Avoro looking glass and to your gateway ip.

    More to provide some background than anything else, to be honest.

    I think @Neoon is actually an Avoro customer.

    Yes, as I said before, as far as I know.
    Avoro resells PHP-Friends and uses the same network.

    I always provided Avoro with all traceroutes/mtr's I had.
    I suppose they forward it.

    Anyway, looking forward to see more uplinks soonTM.

  • Growing pains. I think it's best if clients talk to vendor via correct channel.
    Network route issues may take a day to get escalated and looked at by the right staff, in my experience.

    (disclaimer :Not a php-friends.de client yet.)

    250GB USA RAID6 StorageKVM from €13/yr (no-torrenting, TopProvider)
    (affiliate for 🥰 ) https://clients.inceptionhosting.com/aff.php?aff=401&gid=30

  • PHP_FriendsPHP_Friends Member, Provider
    edited July 14

    @Mahfuz_SS_EHL said:
    I used Hetzner & some other hosts in Germany but @PHP_Friends is getting higher latency than them from My Connection.
    [...]

    I've just answered your ticket, from our point of view there is nearly no difference between First Colo and maincubes (but slightly packet loss over both routes way beyond our networks).


    Anyway, thank you very much that you opened a ticket. This is the only way I can handoff this to the responsible colleagues.

    AMD EPYC NVMe servers located at maincubes FRA01: https://php-friends.de/vserver-ssd

  • AvoroAvoro Member, Provider

    @Neoon said:
    Avoro resells PHP-Friends and uses the same network.

    This is wrong, we have our own racks, switches and also our own hardware. Just because we use the same network does not mean that we simply blindly resell the products :)

Sign In or Register to comment.