×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Comments

top

Toyota Describes Combustion Engine That Generates Electricity Directly

grmoc Some things that make you go "Hmmm" (234 comments)

There were 2 of these 10Kw units required to cruise at 75Mph, so the efficiency, assuming 35% thermal efficiency, is 22mpg.

Given that they're small and easy to maintain, perhaps that doesn't matter if they're only backups, or if this is just a first-iteration technology that may get substantially better.

The big concern imho, is vibration. Unlike a crankshaft-based engine/motor, there is no physical coupling of the pistons if you deploy two of these in a horizontal configuration (as TFA suggests would counter vibration).
The lack of coupling means that the pistons are not mechanically synchronized, which means they don't create forces which act against each other.

I'd have to imagine that one could approximate the physical coupling by varying the timing and mixture, but.. I have no idea how actually effective that'd be.

Anyway.. vibration. Big deal.

about 7 months ago
top

Toyota Describes Combustion Engine That Generates Electricity Directly

grmoc Re:Efficiency? (234 comments)

.. and how efficient is at as compared to a turbine?

about 7 months ago
top

San Francisco's Housing Crisis Explained

grmoc Re:Simple problem, simple solution (359 comments)

Price controls don't do anything to increase the amount of available housing. It just means that people cannot find housing at all, and that the buildings aren't updated.
Eliminating Prop 13, and making the market more liquid and reasonable would help a bit..

about 7 months ago
top

San Francisco's Housing Crisis Explained

grmoc Re:BS (359 comments)

A couple decades back the impact of Prop 13 wasn't yet horribly visible.
Worse, thanks to Prop 13, corporations pay far far less, and thus are less likely to give up property for sale.

about 7 months ago
top

Kickstarted Veronica Mars Promised Digital Download; Pirate Bay Delivers

grmoc Re:Investors? Really? (243 comments)

No, they are NOT investors.
If they were investors,they'd be in trouble with the FTC, which hasn't yet setup regulations allowing such.

People who use Kickstarter are pre-purchasing whatever it is they're being sold. That can act as income for a company, and thus a funding source, but that does not make people who purchase things via Kickstarter investors.

One of these days, we will be able to invest in this manner, but not yet.

about 8 months ago
top

Kickstarted Veronica Mars Promised Digital Download; Pirate Bay Delivers

grmoc Re:Investors? Really? (243 comments)

Kickstarter doesn't do investing. It is a pre-purchase...
I challenge you to find the word "invest" in the below (hint, it isn't there, nor is it *anywhere* on the Kickstarter page)

From Kickstarter:

Pledge $35 or more

  22997 backers

You will receive a digital version of the movie within a few days of the movie’s theatrical debut, plus the T-shirt, plus the pdf of the shooting script. Naturally, you will also receive regular updates and behind-the-scenes scoop throughout the fundraising and movie making process. Available to US, Canada, Australia/New Zealand, Mexico, Brazil, and Select EU countries (Now including Norway and Switzerland! See Project Description for full list)

about 8 months ago
top

Kansas Delays Municipal Broadband Ban

grmoc Re:Come on Common Carrier! (156 comments)

Sign the petition about it:

https://petitions.whitehouse.gov/petition/restore-net-neutrality-directing-fcc-classify-internet-providers-common-carriers/5CWS1M4P

At least it helps it get more noticed.

about 10 months ago
top

Kansas Delays Municipal Broadband Ban

grmoc Re:Good (156 comments)

The low hanging fruit is where the regulations allow them to deploy the most quickly to the largest number of customers.

about 10 months ago
top

Supreme Court Refuses To Hear Newegg Patent Case

grmoc Re: Abolish software patents (204 comments)

The incentive to create is in the money you make from having written and either sold the service that you're selling, or selling the software itself, or sometimes just from the good feeling you get from having made something that works. The latter item is what inspires most really good folks, honestly.

Patents are horrendously ineffective at their intended purpose of incenting innovation in a world where non-practicing entities (read patent trolls) have a vast number of patents and exist with the *sole purpose* being to get money from those patents, and NOT to actually use them. Often the patent is granted (with the application having been secret) years after others have independently gone and done the thing themselves, thinking it was no big deal, probably because *it was no big deal*!
Even worse, many patent holders wait to sue until the idea (or company implementing such) is successful, maximizing the damage.

Worse, most of the patents these days (and there has been an explosion of patents... why orders of magnitude more patents when we're arguably no smarter than we were 10 or 30 years ago??) are fricking obvious.

And of course there is the fun bit that NO COMPANY CAN DO A PATENT SEARCH BECAUSE THEN IT WILLFULLY INFRINGES AND MUST PAY TRIPLE DAMAGES. So, noone looks at patents who actually might use them.

Patents, especially in the realm of software, do more harm than good today.
Strike that. They're almost purely harmful.

about 10 months ago
top

Six Electric Cars Can Power an Office Building

grmoc Re:Screw that. (296 comments)

Yes, and if the batteries are a significant part of the price of the car (true today), this is potentially moving significant expense to the car's owner.

about a year ago
top

Google Fiber In Austin Hits a Snag: Incumbent AT&T

grmoc Re:Utility poles ? You must be kiddin (291 comments)

Ignore the rural parts which account for most of the area and just focus on the metro areas, and you'll find that the US *STILL* is way behind.

about a year ago
top

Taking Google's QUIC For a Test Drive

grmoc Re:Morons (141 comments)

And sorry if I sound frustrated about it... I am *really* frustrated by the current state of the world w.r.t. parallel connections. It makes my life such a pain in the butt!

1 year,16 days
top

Taking Google's QUIC For a Test Drive

grmoc Re:Morons (141 comments)

TCP implementations are very mature. As impementors, we've fixed most/many of the bugs, both correctness and performance related. TCP offers reliable delivery, and, excepting some particular cases of tail-loss/tail-drop, knows the difference between packets that are received but not delivered and packets that are neither received nor delivered.
TCP has congestion control in a variety of different flavors.
TCP has various cool extensions, e.g. MPTCP, TCP-secure (not an RFC, but a working implentation), TFO, etc. etc.

You said streams. I agree that HOL blocking is solved by multiplexing over something, whether that be streams or connections, or messages.

That being said...
HOL blocking is NOT NOT NOT NOT NOT NOT NOT NOT solved with concurrent *connections*, because while doing so solves the HOL blocking problem, it opens up a greater number of cans-of-worms.
If one creates many connections:
I don't want to see more congestion in the connection startup phase since we're creating 60 connections (not an exaggeration) each with between 1-10 packets. I don't want to see poorer congestion avoidance because of the multiple connections. I'm tired of having each one of these connections land on a different server, and losing all ability to optimize what resources are being sent vs inlined because of the complexity inherent in attempt to rectify this. I don't want to have to expand the congestion window on X connections with short flows. I don't want to have to deal with tail-drop on X flows, etc. etc.

1 year,16 days
top

Taking Google's QUIC For a Test Drive

grmoc Re:Thank you (141 comments)

Wait, what? :)
Where was that claimed?!

In any case:
TCP's implementations are almost without fail doing per-flow congestion control, instead of per-session congestion control/per-ip-ip-tuple congestion control. This implies that, if loss on path is mostly independent (and that is what data seems to show), per-flow congestion control backs off at a constant factor (N where N == number of parallel connections) more slowly than a single stream between the same endpoints would.

So, indeed, sending several files in parallel has a potential for going faster when on links with independently correlated packet loss.

This sucks, by the way, because it makes the lives of those folks working on HTTP2 more difficult.

1 year,16 days
top

Taking Google's QUIC For a Test Drive

grmoc Re:It's not broken... (141 comments)

I think that you're forgetting that packet loss on a TCP stream incurs a retransmit.
So, when there is 33% loss, you end up sending rexmits with an overhead of 50% (33% of the first 33% lost would also be lost, etc. so the series of sum of (p^i) where p ==1/3 and i goes from 1->infinity converges at 50%)

In any case, you end up with an overhead of packets/bytes on the wire with rexmits as well.

With XOR based FEC, it takes one FEC packet at MTU size to recreate any one lost packet in the range of packets covered by the FEC. This means that, so long as your flow is long enough, FEC becomes potentially superior at recovering data, as the FEC can cover a longer range packets, making multiple-packet-recoveries possible. This really depends on the length of the flow, however, and it is certainly true that FEC by itself is never sufficient.

Comparing the two:
FEC: is good since it has a probability of removing an RTT before the application can interpret the data. It is not as great when one focuses on bandwidth efficiency in a non-loss case. It can potentially do better in terms of bandwidth efficiency than rexmit at higher loss rates since the FEC packet can deal with any one packet being lost within the range.

Rexmit: is good since it uses no additional bandwidth in the no-loss case. It is potentially a fair bit worse when there is loss (the internet seems to average ~1.5% packet loss) in terms of latency for the application, and it isn't great in terms of bandwidth efficiency when loss is occuring.

Both FEC and rexmit seem like reasonable loss recovery mechanisms, each excels at different parts of the curve.

1 year,16 days
top

Taking Google's QUIC For a Test Drive

grmoc Re:It's not broken... (141 comments)

Part of the focus is on mobile devices, which often achieve fairly poor throughput, with large jitter and moderate to large RTTs. .. so, yes there is attention to low bandwidth scenarios.
Surprisingly, QUIC can be more efficient given how it packs stuff together, but there this wasn't a primary goal.
Think about second-order effects:
Given current numbers, if FEC is implemented, it is likely that it would reduce the number of bytes actually fed to the network, since you end up sending fewer retransmitted packets than you send FEC packets since the FEC packets allow for any one packet in the range of packets it covers to be reconstructed!

1 year,19 days
top

Taking Google's QUIC For a Test Drive

grmoc Re:Benchmarking premature; QUIC isn't even 100% co (141 comments)

Nah; it is valuable for many people to be doing this benchmarking even with the current state of code. .. it just requires careful explanation of what the benchmark entails!

Concluding that buggy-unfinished-QUIC is slower than TCP is absolutely valid, for instance.
That isn't the same as QUIC being slower than TCP (at least, not yet!)

1 year,19 days
top

Taking Google's QUIC For a Test Drive

grmoc Re:Morons (141 comments)

TCP doesn't suck.

TCP is, however, a bottleneck, and not optimal for all uses.

Part of the issue there is the API-- TCP has all kinds of cool, well-thought-out machinery which simply isn't exposed to the application in a useful way.

As an example, when SPDY or HTTP2 is layered on TCP, when there is a single packet lost near the beginning of the TCP connection, it will block delivery of all other successfully received packets, even when that lost packet would affect only one resource and would not affect the framing of the application-layer protocol.

1 year,19 days
top

Taking Google's QUIC For a Test Drive

grmoc Re:Thank you (141 comments)

bprodoehl is absolutely correct-- the code is unfinished, and while the scenario is certainly one which is worried about, it isn't the focus of attention at the moment. The focus at the moment is getting the protocol working reliably and in all corner cases... Some of the bugs here can cause interesting performance degredations, even when the data gets transferred successfully.

I hope to see the benchmarking continue!

1 year,19 days

Submissions

top

SPDY makes Google search faster

grmoc grmoc writes  |  more than 2 years ago

grmoc (57943) writes "On the Google code blog: "... thanks to SPDY, a significant percentage of Chrome users saw a decrease in search latency when we launched SSL-search."
                Also,
"With the help of Mozilla and other contributors, we’re pushing hard to finalize and implement SPDY draft-3 in early 2012, as standardization discussions for SPDY will start at the next meeting of the IETF. ""

Link to Original Source
top

Slashdot (and the rest of the web) 2X faster?!

grmoc grmoc writes  |  about 5 years ago

grmoc (57943) writes "As part of the "Let's make the web faster" initiative, we (a few engineers (including me!) at Google, and hopefully people all across the community soon!) are experimenting with alternative protocols to help reduce the latency of web pages. One of these experiments is SPDY (pronounced "SPeeDY"), an application-layer protocol (essentially a shim between HTTP and the bits on the wire) for transporting content over the web, designed specifically for minimal latency. In addition to a rough specification for the protocol, we have hacked SPDY into the Google Chrome browser (because its what we're familiar with) and a simple server testbed. Using these hacked up bits, we compared the performance of many of the top 25 and top 300 websites over both HTTP and SPDY, and have observed those pages load, on average, about twice as fast using SPDY.. Thats not bad!

We hope to engage the open source community to contribute ideas, feedback, code (we've open sourced the protocol, etc!), and test results!"

Journals

grmoc has no journal entries.

Slashdot Login

Need an Account?

Forgot your password?