ViewQwest Fiber Broadband Official Thread - Part 3

[andr3wyong]

I started with nothing and drooling over .....

Ok let me rephrase. Monkey start tiny and dream medium sized. Haha!

 

[kira86]

Use at least an i7 ah

my name not maylyn
just gonna test out esxi this weekend, if can work then good, if not then too bad

 

[andr3wyong]

That's because you have plentiful of space where your bedroom = my entire house.

Ok lah on the bright side it has served as a demo project even before completion as it has basically transformed my house into a UniFi + Freedom VPN + Apple ecosystem + Fire TV showcase.

Meaning to say that if a few systems integration projects I picked up along the way pay off, then the home infra pays for itself

 

[maylyn]

Hi Maylyn,

I've installed the new beta2 merlin firmware on my AC68u, same problem started happening again, the 5ghz wifi started going to channel 36, 20MHz all on its own, regardless of setting.

One thing I noted though, if i set the wireless mode to Auto, its will respect the settings that I've set. If i set it to N+AC, then it jumps back to channel 36, 20Mhz regardless.

Could you feedback this to RMerlin perhaps?

Nothing have changed .... besides the addition of the fixes as what have been posted.

376.44-beta2 (29-Jul-2014)
  - NEW: HFS+ support for MIPS devices (N16/N66/AC66).
         N16 also uses Tuxera now.
  - CHANGED: Updated N66U driver to Asus's 1071 build
  - CHANGED: Implemented RT-AC87U report of LAN port 4
  - FIXED: RT-AC87U port order was wrong on Sysinfo page
  - FIXED: Minidlna issues with Philips smart TVs
  - FIXED: Incorrect state report of port 1 on AC87U.  
           MAC and VLAN cannot be retrieved (AC87U)
  - FIXED: SSHD brute force protection wasn't working if
           Dual WAN was enabled and set to LB mode.
  - FIXED: Miniupnpd error flood in Syslog when using a
           Plex server on your LAN

It's getting pretty oddly weird in your case which shouldn't be, can you do a hard reset and see whether Beta 2 works for you, if it's still the same, revert back to Beta 1 and feedback accordingly.

I will suggest you might want to wait out until a more official RMerlin release is out before updating the firmware since Beta 1 works for you.

We are past Beta 3 and RMerlin should have a official release soon.

 

[andr3wyong]

Plus thanks to a few permanent (bricks + cement + putty + paint) mistakes made by my electrician, I can also showcase some of the mistakes that homeowners need to plan around way BEFORE starting any renovation or furniture carpentry.

 

[maylyn]

my name not maylyn
just gonna test out esxi this weekend, if can work then good, if not then too bad

Just loiter @ HWZ/VRZ marketplace and check out if there are any good Intel processors up for sale within your budget or sellers want to sell away cheaply get it and do something something something later and just RMA

Please make sure that the Intel processors you wants to get are still within warranty period, don't come back saying Intel reject your RMA loh

 

[andr3wyong]

Just loiter @ HWZ/VRZ marketplace and check out if there are any good Intel processors up for sale within your budget or sellers want to sell away cheaply get it and do something something something later and just RMA

This something something something technique ah… lol

 

[maylyn]

This something something something technique ah… lol

Up for your imagination As if you don't know .... orh .... lol

 

[afiqqq]

Depending on the quality of your Ethernet cables, switch as well as length of cable, I noticed that enabling EEE/Green Ethernet/Cable Length Detect can seriously (940->850Mbps) affect throughput.

However if your cables are made until very solid or it's just a short run then there shouldn't be too much difference in performance (and you do save a tiny bit of power due to the much lower voltages used for the short cable)

Anyway having network-wide EEE is more if you think in terms of datacenter/building size deployments where thousands of patch cables' power savings adds up

True. The features apply more to mass deployments where almost all of ones bandwidth is taken up almost all the time.

 

[edwin21]

This is due to BGP taking time to recover routes as the network topology changes.

At the same time some higher bandwidth routes might also have higher latency, which for some uses such as lower thread downloads or game servers hosted in OVH range causes issues with other subscriber's needs.

At the end of the day it's an easy balance to make but since OVH is a contiguous network without different AS number to differentiate bulk file services vs game servers vs general hosting, it is a compromise between the needs of different users.

Eg due to GFW China, some links in are heavily congested while others with less congestion might take a hit in latency. Once again a compromise has to be met between latency sensitive and BW intensive uses.

However due to domestic users taking priority or in the case of OVH serving a particular type of clientele, they are not motivated to work with ISPs on alleviating these issues.

didn't VQ has a direct route via seabone to OVH? or peering with OVH london?
and neither provide good enough capacity?

if u say latency over bandwidth, then why the difference?

the forward route for the past few days

Tracing route to 178.33.81.11 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  core-router.mtk [10.0.0.1]
  2    <1 ms    <1 ms    <1 ms  viewqwest.net-101.erl [10.1.0.1]
  3     2 ms     1 ms     1 ms  fnet1-f88-access.vqbn.com.sg [132.147.88.1]
  4     1 ms     1 ms     1 ms  v-tr-eqx-01.vqbn.com [202.73.37.232]
  5  1342 ms  1007 ms   305 ms  switch.equinix.vqbn.com [202.73.47.6]
  6     5 ms     4 ms     4 ms  ip-176-198.moratelindo.co.id [202.43.176.198]
  7   185 ms   184 ms   184 ms  116.51.26.165
  8   183 ms   183 ms   183 ms  as-3.r21.sngpsi02.sg.bb.gin.ntt.net [129.250.3.57]
  9   186 ms   185 ms   185 ms  ae-6.r00.sngpsi02.sg.bb.gin.ntt.net [129.250.6.105]
 10     3 ms     3 ms     3 ms  ae0.singapore2.sin.seabone.net [93.186.133.12]
 11   189 ms   189 ms   188 ms  xe-2-1-0.milano51.mil.seabone.net [195.22.208.53]
 12     *        *        *     Request timed out.
 13   237 ms     *        *     mil-5-6k.it.eu [94.23.122.251]
 14     *      263 ms     *     fra-5-6k.fr.eu [91.121.128.35]
 15   249 ms   224 ms   202 ms  rbx-g2-a9.fr.eu [178.33.100.244]
 16   233 ms   244 ms   242 ms  rbx-s14-6k.fr.eu [178.33.100.47]
 17   250 ms   260 ms   237 ms  178.33.81.11

Trace complete.

the forward route taken in early july

Tracing route to s11.alldebrid.com [178.33.81.11]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  core-router.mtk [10.0.0.1]
  2    <1 ms     1 ms    <1 ms  viewqwest.net-101.erl [10.1.0.1]
  3     2 ms     2 ms     2 ms  fnet1-f88-access.vqbn.com.sg [132.147.88.1]
  4     2 ms     2 ms     2 ms  v-pr-eqx-02.vqbn.com [202.73.37.230]
  5     *        *      188 ms  sw1.tc.lon.ovh.net [195.66.224.220]
  6   192 ms   192 ms   193 ms  rbx-g2-a9.fr.eu [91.121.131.243]
  7   192 ms     *        *     rbx-s14-6k.fr.eu [178.33.100.47]
  8   192 ms   192 ms   194 ms  178.33.81.11

Trace complete.

edit: to addon, right now the download speed from alldebrid servers (3-4 different servers from OVH network at the same time) is capped at 100mbps total

 

[andr3wyong]

didn't VQ has a direct route via seabone to OVH? or peering with OVH london?
and neither provide good enough capacity?

if u say latency over bandwidth, then why the difference?

the forward route for the past few days

Tracing route to 178.33.81.11 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  core-router.mtk [10.0.0.1]
  2    <1 ms    <1 ms    <1 ms  viewqwest.net-101.erl [10.1.0.1]
  3     2 ms     1 ms     1 ms  fnet1-f88-access.vqbn.com.sg [132.147.88.1]
  4     1 ms     1 ms     1 ms  v-tr-eqx-01.vqbn.com [202.73.37.232]
  5  1342 ms  1007 ms   305 ms  switch.equinix.vqbn.com [202.73.47.6]
  6     5 ms     4 ms     4 ms  ip-176-198.moratelindo.co.id [202.43.176.198]
  7   185 ms   184 ms   184 ms  116.51.26.165
  8   183 ms   183 ms   183 ms  as-3.r21.sngpsi02.sg.bb.gin.ntt.net [129.250.3.57]
  9   186 ms   185 ms   185 ms  ae-6.r00.sngpsi02.sg.bb.gin.ntt.net [129.250.6.105]
 10     3 ms     3 ms     3 ms  ae0.singapore2.sin.seabone.net [93.186.133.12]
 11   189 ms   189 ms   188 ms  xe-2-1-0.milano51.mil.seabone.net [195.22.208.53]
 12     *        *        *     Request timed out.
 13   237 ms     *        *     mil-5-6k.it.eu [94.23.122.251]
 14     *      263 ms     *     fra-5-6k.fr.eu [91.121.128.35]
 15   249 ms   224 ms   202 ms  rbx-g2-a9.fr.eu [178.33.100.244]
 16   233 ms   244 ms   242 ms  rbx-s14-6k.fr.eu [178.33.100.47]
 17   250 ms   260 ms   237 ms  178.33.81.11

Trace complete.

the forward route taken in early july

Tracing route to s11.alldebrid.com [178.33.81.11]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  core-router.mtk [10.0.0.1]
  2    <1 ms     1 ms    <1 ms  viewqwest.net-101.erl [10.1.0.1]
  3     2 ms     2 ms     2 ms  fnet1-f88-access.vqbn.com.sg [132.147.88.1]
  4     2 ms     2 ms     2 ms  v-pr-eqx-02.vqbn.com [202.73.37.230]
  5     *        *      188 ms  sw1.tc.lon.ovh.net [195.66.224.220]
  6   192 ms   192 ms   193 ms  rbx-g2-a9.fr.eu [91.121.131.243]
  7   192 ms     *        *     rbx-s14-6k.fr.eu [178.33.100.47]
  8   192 ms   192 ms   194 ms  178.33.81.11

Trace complete.

The direct route is good for latency but bandwidth was not satisfactory compared to Seabone.

Actually when New York is up, there should be improvement to bandwidth and/or latency as there are more options available for OVH route.

There are also future plans on the cards for investing in more international infrastructure to stay ahead of the curve but so far nothing to announce I'm afraid.

Okay lah, VQ network not stagnant. Definitely room for new POPs and international links.

Oldies ISPs have the benefit of international infra ownership but as a smaller player VQ can cherry pick and optimize rather than maximizing revenue for any particular pipe.

At least with VQ a substantial part of fees go into these expansion roadmaps, something cheaper ISPs can't begin to even think about.

I'll see what can be done about OVH when NY is up.

 

[edwin21]

The direct route is good for latency but bandwidth was not satisfactory compared to Seabone.

Actually when New York is up, there should be improvement to bandwidth and/or latency as there are more options available for OVH route.

There are also future plans on the cards for investing in more international infrastructure to stay ahead of the curve but so far nothing to announce I'm afraid.

Okay lah, VQ network not stagnant. Definitely room for new POPs and international links.

Oldies ISPs have the benefit of international infra ownership but as a smaller player VQ can cherry pick and optimize rather than maximizing revenue for any particular pipe.

At least with VQ a substantial part of fees go into these expansion roadmaps, something cheaper ISPs can't begin to even think about.

I'll see what can be done about OVH when NY is up.

if direct not as good as seabone, why not direct via seabone instead of going thru PT. Mora Telematika Indonesia/NTT.SG then seabone

the download is like depend on mood, happy it give >300mbps for some of the past few nights, today not happy, trottle down to 100mbps?

 

[spiritual84]

Nothing have changed .... besides the addition of the fixes as what have been posted.

376.44-beta2 (29-Jul-2014)
  - NEW: HFS+ support for MIPS devices (N16/N66/AC66).
         N16 also uses Tuxera now.
  - CHANGED: Updated N66U driver to Asus's 1071 build
  - CHANGED: Implemented RT-AC87U report of LAN port 4
  - FIXED: RT-AC87U port order was wrong on Sysinfo page
  - FIXED: Minidlna issues with Philips smart TVs
  - FIXED: Incorrect state report of port 1 on AC87U.  
           MAC and VLAN cannot be retrieved (AC87U)
  - FIXED: SSHD brute force protection wasn't working if
           Dual WAN was enabled and set to LB mode.
  - FIXED: Miniupnpd error flood in Syslog when using a
           Plex server on your LAN

It's getting pretty oddly weird in your case which shouldn't be, can you do a hard reset and see whether Beta 2 works for you, if it's still the same, revert back to Beta 1 and feedback accordingly.

I will suggest you might want to wait out until a more official RMerlin release is out before updating the firmware since Beta 1 works for you.

We are past Beta 3 and RMerlin should have a official release soon.

Actually... I'm not sure that Beta 1 was any different from Beta 2... after hard reset perhaps the setting went to Auto somehow instead of N+AC? I didn't take note.

Anw yeah i tot since it was Beta I might just provide some feedback hehe. It just smells a bit funky that the router will automatically revert to channel 36 and 20Mhz regardless of settings... shld be just a line or two of code that's out of place. No worries la I'd just wait and see if the official release has the same problem...

 

[kitsura]

my name not maylyn
just gonna test out esxi this weekend, if can work then good, if not then too bad

i7 so cheap now, I can sell you my 2nd hand i7 2700K since my mobo is dead and i am most likely going to upgrade the whole rig.

 

[andr3wyong]

if direct not as good as seabone, why not direct via seabone instead of going thru PT. Mora Telematika Indonesia/NTT.SG then seabone

the download is like depend on mood, happy it give >300mbps for some of the past few nights, today not happy, trottle down to 100mbps?

Did the return route change, by any chance?

 

[roo7]

you can get another one in the vq e-store!

e-store.viewqwest.com

Nice.... thanks for the heads up..

 

[kira86]

i7 so cheap now, I can sell you my 2nd hand i7 2700K since my mobo is dead and i am most likely going to upgrade the whole rig.

Tempting how much?

 

[kitsura]

Tempting how much?

Not sure, PM me your offer price.

 

[kira86]

Not sure, PM me your offer price.

will PM u soon.
any 1Gbps users here ?

 

[maylyn]

will PM u soon.
any 1Gbps users here ?

Reporting in

1). Maylyn