For those on google fiber tv, what client are you using?

[twitch]

Since post merger, just curious if anyone has been able to use their sage clients or hd 300 boxes to watch google fiber tv?

On my info page it says Sage TV 8 client which is not otherwise available (other than from google I understand)

[Brent]

I should be able to confirm this by next month roughly.

I've been told that the SageTV extenders will not be recognized by Google Fiber. I wish that weren't true. Once I'm on Google Fiber I'll confirm. Right now fiber has been run throughout all the streets/sidewalks in my fiberhood so they are now connecting building-by-building, unit-by-unit as most of my hood is multi-tenant buildings.

PS: You from KC also?

[twitch]

Yeah, KCMO.

I have had google fiber for about a month now. Their tv interface is not well optimized. Sure wish we could tweak it. Also, I would like to be able to watch tv on my laptop/computers. Was wondering if I had a sage client if it would let me watch tv.

The internet speed is nice, btw:

[mdnttoker]

Originally Posted by twitch

Yeah, KCMO.

I have had google fiber for about a month now. Their tv interface is not well optimized. Sure wish we could tweak it. Also, I would like to be able to watch tv on my laptop/computers. Was wondering if I had a sage client if it would let me watch tv.

The internet speed is nice, btw:

Wow...salivating over those stats!!

[Fuzzy]

One would hope there is still a plugin system buried in there that could be leveraged - just a matter of getting into it. I promise if they expand it to my neighborhood, I will work hard at it.

[twitch]

Originally Posted by Fuzzy

One would hope there is still a plugin system buried in there that could be leveraged - just a matter of getting into it. I promise if they expand it to my neighborhood, I will work hard at it.

I assume attempting to connect with a v7 or hd300 client would be futile? Just odd that I can't watch for a service that I am paying for on any device I want.

[wayner]

Originally Posted by twitch

Yeah, KCMO.The internet speed is nice, btw:

What router do you have? Many routers can't handle WAN/LAN throughput anywhere near 1Gig. See http://www.smallnetbuilder.com/lanwan/router-charts/

[Brent]

Originally Posted by wayner

What router do you have? Many routers can't handle WAN/LAN throughput anywhere near 1Gig. See http://www.smallnetbuilder.com/lanwan/router-charts/

That list is a bit dated honestly. Some of the routers they grade down for the early firmware, but never updated after they first came out. I have the Asus RT-AC66U which has been mentioned as one of the favorites by the few Google Fiber users I know. There are several worthy routers that can handle 1Gig now. But for many it will mean buying a new one when they do get Gigabit...

[wayner]

Thanks Brent - I have 100Mbps service now that can run up to 150Mbps if I upgrade my modem - the issue is that I don't think my Asus RT-N16 can handle the speed.

p.s. It is nice to see your blog back in operation and I look forward to reading about Google Fiber/SageTV8

[wayner]

By the way Twitch -you're getting ripped off

The difference between your actual speeds and the advertised speed is over 50 Mbps - that is about 10X faster than the average broadband in the country!

[drewg]

Originally Posted by wayner

By the way Twitch -you're getting ripped off

The difference between your actual speeds and the advertised speed is over 50 Mbps - that is about 10X faster than the average broadband in the country!

To be serious for a second, most of these benchmarks use TCP, and report the end to end throughput to the application. On an ethernet network, there is roughly 78-90 bytes of overhead inside each ethernet frame:
14b ethernet header
20b IPv4 header (or 40b IPv6)
20b TCP header (not including timestamp option, 32b with timestamps)
---
For a total of 54 bytes overhead, so you have 1460b of payload (or 66b overhead with TCP timestamps, and 1448b payload).

Then there is more overhead outside the frame: 8 bytes of preamble & framing before the frame, 4 bytes of ethernet CRC after the frame, and a 12 byte inter-packet gap, for a total of 24b overhead.

So, assuming no TCP timestamps, the best you can do is use 1460b out of every frame, which is : 1460/(1514 + 24) = 0.949
And with timestamps, that number becomes 1448 /(1514+24) = 0.941

Or about 94-95% of the link speed. So he's getting EXACTLY what he's paying for.

Now: If anybody is still awake -- Will the Google Fiber TV extenders connected to a SageTV V7 server?? That's what I want to know!


Drew

[wayner]

Originally Posted by drewg

Now: If anybody is still awake -- Will the Google Fiber TV extenders connected to a SageTV V7 server?? That's what I want to know!

Hopefully Brent can tell us this when he is up and running.

[cat6man]

Originally Posted by drewg

To be serious for a second, most of these benchmarks use TCP, and report the end to end throughput to the application. On an ethernet network, there is roughly 78-90 bytes of overhead inside each ethernet frame:
14b ethernet header
20b IPv4 header (or 40b IPv6)
20b TCP header (not including timestamp option, 32b with timestamps)
---
For a total of 54 bytes overhead, so you have 1460b of payload (or 66b overhead with TCP timestamps, and 1448b payload).

Then there is more overhead outside the frame: 8 bytes of preamble & framing before the frame, 4 bytes of ethernet CRC after the frame, and a 12 byte inter-packet gap, for a total of 24b overhead.

So, assuming no TCP timestamps, the best you can do is use 1460b out of every frame, which is : 1460/(1514 + 24) = 0.949
And with timestamps, that number becomes 1448 /(1514+24) = 0.941

Or about 94-95% of the link speed. So he's getting EXACTLY what he's paying for.

Now: If anybody is still awake -- Will the Google Fiber TV extenders connected to a SageTV V7 server?? That's what I want to know!


Drew

excellent analysis but if anyone else is still awake, this can only be achieved in one direction if the other direction is unloaded. typically 2-3% of the rate in one direction is required in the other direction to support TCP ACK signaling. also, simultaneous UL/DL transmission will reduce achievable rates.

now the geek in me really wants to know: is that 1ms real or do they just not support decimal places and round up to 1ms????

[Brent]

You guys are way, way ahead of me. When I get my Google Fiber installation finally I need to have some of you smart, tech guys to visit so we can really see what this Google Fiber & FiberTV can do

[Fuzzy]

Back to the router front, I, personally, have switched to an old Atom board running pfsense. WAY faster than most consumer routers, has a lot of great plugins, and some great features (like HTTP caching, for instance).

[bcjenkins]

Originally Posted by Fuzzy

Back to the router front, I, personally, have switched to an old Atom board running pfsense. WAY faster than most consumer routers, has a lot of great plugins, and some great features (like HTTP caching, for instance).

pfSense FTW!

[Fuzzy]

Originally Posted by bcjenkins

pfSense FTW!

The funny thing is, I never even got around to buying a case for the thing - I've got my router currently running on this old atom board, neatly installed in a cardboard box from newegg... stay classy!

[bcjenkins]

I run mine on a Super Micro Atom server. Rack mounted with IPMI.

[twitch]

Well if anyone is in town and wants to bring their hd300 extender or sage client with them and try it out on the google fiber network, please let me know

As far as my router, it is the google fiber router which is Gig E. I'm able to transfer files within my local network at close to the full GigE. From external servers, is a different story.

[drewg]

Originally Posted by cat6man

excellent analysis but if anyone else is still awake, this can only be achieved in one direction if the other direction is unloaded. typically 2-3% of the rate in one direction is required in the other direction to support TCP ACK signaling. also, simultaneous UL/DL transmission will reduce achievable rates.

Well, if its one connection running bidirectionally, then the data segments carry the acks for the other direction, and you loose nothing.

If its 2 (or more) connections, things get much more complex, and you tend to loose more bandwidth than you'd expect because the acks from one connection can get queued behind the data for the other connection, so it introduces artificial delay due to the queuing overhead. With a lan, and a NIC & OS that supports multiple TX & RX queues, most of this goes away & you're left with just the loss due to the acks. With typical consumer h/w, everything uses single queues, and you have the extra queuing delays due to the entire path from app to app (and not just the link) being carried in a single queue.

Drew