Forum Replies Created

Page 19 of 32
  • Steve Modica

    June 4, 2011 at 12:42 am in reply to: Raw Footage, No Contract, No Deal

    Having gone through contractual disputes before, here’s my take:
    It costs about $5k to have a lawyer file something for you properly. It would cost about $25k to take it to court and another 25k to get through the case. It’s very unlikely the guys going to have that kind of coin laying around.
    He could take you to small claims court, but as the previous post says, there’s no contract! So what exactly is he suing for? Sit tight. You are in the driver seat in my view. No money, no tapes. He can make you an offer.

    Steve Modica
    CTO, Small Tree Communications

  • Steve Modica

    June 4, 2011 at 12:36 am in reply to: Thunderbolt

    My .02:
    There won’t be Thunderbolt switches. switching asics are expensive and the only switched technology that is cheap enough to make a switch you’ll pay for is ethernet (etherNOT never wins).

    So, Tbolt will be a PCIE/firewire replacement and probably lead to smaller systems (ala imac) that can have 10Gb and Aja cards without the extra space and cost of a full PCIE card cage.

    We’re working on 10Gb on Tbolt now. Lucky for us, the driver work is done. We just have to do the hardware.
    Current Tbolt hardware is glitchy and involves many chips. Late summer will bring a smaller chipset that is easier to manage and is more widely available. I don’t think you’ll see wide adoption til we get those.

    Steve Modica
    CTO, Small Tree Communications

  • Steve Modica

    June 4, 2011 at 12:32 am in reply to: Is link aggregation the solution?

    [Andrew Richards] “Aside: has TOE ever been attempted on OS X? I know on Linux it requires kernel extensions as well as drivers..”

    Not really. Neterion tried and had a large hardware abstraction layer. They kept telling me it was done, but the driver never released and was always “alpha” and you had to ask them to mail it to you. They never mailed it to me 🙂

    Chelsio did a slow path driver (no TOE), and claimed they would have TOE later. From my understanding, the upper management of software within apple has no intention of putting in the kernel TCP stack hooks to let that happen. (I’ll explain that in a sec)

    We tried to do it with Intel’s “quickdata” dma offload engine. That was an exciting project. We got the design all completed and then Intel decided not to move forward with the chip, so we were screwed. But even in that case, we needed some Apple help to make that work.

    So what’s needed??
    Ultimately, when you transmit data out of the machine, the OS puts the data into mbufs. It has to keep these around in case they get lost and have to be retransmitted. however you are writing to your socket buffer and could care less that the OS needs to keep those buffers. You’ll happily overwrite them. So the OS has to copy them off to a safe place in the kernel. So all your data is memcopied before it hits the network. This uses a *lot* of cpu. Each word has to go through a ld/sd operation.

    TOE and quickdata were supposed to subvert this. However to do that in the BSD kernel stack, there’s a check to see if an offload path exists. If so, it’s called rather than the normal memcopy. Apple does not have this check and has not wanted to put it in. Hence, no TOE.

    (Historical note: Dave Miller hated TOE and refused to let it into the Linux stack. So those guys all had to release kernel patches to support their stuff. That was a huge hassle and was yet another reason TOE failed)

    Steve Modica
    CTO, Small Tree Communications

  • Steve Modica

    June 3, 2011 at 11:45 pm in reply to: how to know where file is getting written

    fs_usage might show you the device file. (It does not show that on my system, but I don’t have FC drivers installed)

    Steve Modica
    CTO, Small Tree Communications

  • Steve Modica

    June 3, 2011 at 11:33 pm in reply to: Is link aggregation the solution?

    Right! It’s the same deal tho. You connect to the share using the 10Gb IP address. The routing issues probably apply. If you have two ports on the same subnet, you are essentially lying to the OS. Since they are on the same subnet, the OS *thinks* that both ports can hear the same packets, but in real life, they can’t. So it will send packets out one port for *both* ip addresses. (old problem)

    Steve Modica
    CTO, Small Tree Communications

  • Steve Modica

    June 3, 2011 at 11:15 pm in reply to: Is link aggregation the solution?

    Routing is handled automatically depending on how you do the mounts.
    The ports cannot be on the same subnet (or the kernel routing table will get confused).

    When you mount the other machine, use “connect to server” and give the 10Gb address. That will automagically route over the 10Gb. Then you can drag the mount down to the tool bar to save it.

    Steve Modica
    CTO, Small Tree Communications

  • Steve Modica

    June 3, 2011 at 4:31 pm in reply to: INFORTREND Speed….

    It is generally the case the OS striping code is designed to stripe drives and will use an extremely small interleave for your raids. That means they will be getting very small IOs and those are inefficient for a raid. I would suggest not striping them and seeing what you get.

    Steve Modica
    CTO, Small Tree Communications

  • Steve Modica

    June 3, 2011 at 1:59 am in reply to: Is link aggregation the solution?

    [Alex Gerulaitis] “If my calculations are right, 100GB/hr is about 28MB/s which is roughly 25% of the GigE line rate; he should be able to get much higher speeds by optimizing his NICs, possibly using jumbo frames and a faster switch.”

    Good catch. I actually scanned that and just read it as “100MB/sec” assuming he was talking about gigabit speed.

    he should be seeing 90MB/sec pretty solid if he’s moving a large file.
    30MB/sec is really horrible.

    Steve Modica
    CTO, Small Tree Communications

  • Steve Modica

    June 3, 2011 at 1:37 am in reply to: Is link aggregation the solution?

    [Alex Gerulaitis] “From what I understand, you could do it for $1110: two Intel 10Gigabit AT2 Server Adapters for about $550 each, a cross-over Cat6 cable ($10 or so), and you are all set – as long as you are only interested in speeding up a file transfer between two stations. According to Steve, you should see 300MB/s if the drives can handle it. Like Steve said, the weak link (after you upgrade to 10GigE) will be your dual-drive RAID0 (200-280MB/s are most common speeds).

    Two comments:
    The Intel cards won’t work in a mac without a driver. So the small tree cards are the only option for those
    Cross over cables are no longer required (since gigabit)

    Or, you could go with Small Tree Comms for about $1000-2000 more and get even higher speeds.”

    I think his limitation would be the raid0 stripe. I think before moving to a faster network, they should consider more drive spindles on the edit machines.

    Steve Modica
    CTO, Small Tree Communications

  • Steve Modica

    June 3, 2011 at 12:22 am in reply to: Is link aggregation the solution?

    One more thing:
    AFP (and Samba) do a lot of consistency checking since they are shared protocols. So they stat files and directories very frequently. When we put together blazeFS a long time ago, reducing that was one of our primary goals. That’s a big contributor to the overhead.

    You can watch all that happen with tcpdump.

    Steve

    Steve Modica
    CTO, Small Tree Communications

Page 19 of 32

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy