Skip to first unread message
Vicraj Thomas
Dec 13, 2013, 4:02:48 PM12/13/13
to Dong Mo, geni-...@googlegroups.com
Moving this conversation from he...@geni.net to geni-users:
Background: Dong Mo stitched a 900Mbps link between the Utah DDC rack
and the U. of Missouri rack. The actual throughput he got on the link
was much lower (~200 Mbps of UDP traffic).
geni-users: Please feel free to add to or correct my responses to Mo.
On 12/13/13 1:43 PM, Dong Mo wrote:
> Hi all,
>
> 1.What is "reserve" means here? Does it means that no other traffic can
> flow on the reserved link at the reserved time and I own the reserved
> capacity by my own?
>
By "reserve" if you mean creating the GMOC ticket about your potentially
disruptive experiment, all that does is inform the affected aggregates
that you'll be running an experiment that is potentially disruptive.
There is no actual resource reservation that happens.
When you stitched the link between Utah DDC and U. of Missouri, a VLAN
was set up for you between the two racks and the VLAN capacity was set
to 900 Mbps (the capacity you specified) at the switches the VLAN went
through. All this means is the switches will allow up to 900 Mbps of
traffic on your VLAN. I don't think your VLAN is given any higher
priority and so you are still competing for link bandwidth with other
connections.
> I am asking about this because when I set the capacity of stitched link
> to 900Mbps, what I can really get is only about 200Mbps.
>
> Note that by "get" I mean I use UDP traffic to saturate the link at
> 1Gbps from one site to another but at the receiving end, the perceived
> throughput is only 200Mbps. I know there could be limitation of TCP and
> other protocols, so that 900Mbps cannot be reached use them. But I am
> not using any congestion protocol but only flooding in the network on
> 1G, however, what I can get is only 200Mbps.
>
I don't know why you got only 200 Mbps. It could be something in the
network or something at the end hosts. I think you stitched together
two OpenVZ containers and I don't know if the virtualization layer is
limiting your bandwidth. You might want to get a raw PC at two racks
and run your experiment again. This will tell you if it is the network
or the OS/virtualization that is the bottleneck.
I also suggest starting with a lower bandwidth link (say 500 Mbps) to
see if you get that with raw PCs. You will not need to coordinate with
the GMOC or the aggregate providers to try this out.
> 2. Why I could not write 1000000 at the capacity option in the rspec? It
> seems I can only specify some value smaller than that. Is this a bug for
> stitcher.py or omni?
>
I do not know why your attempt to stitch a 1Gbps link failed at the
Missouri aggregate. It is possible the switch there was unable to
provision a 1Gbps VLAN for you at that site because of others already
having reserved bandwidth there.
Best wishes,
< Vic
Background: Dong Mo stitched a 900Mbps link between the Utah DDC rack
and the U. of Missouri rack. The actual throughput he got on the link
was much lower (~200 Mbps of UDP traffic).
geni-users: Please feel free to add to or correct my responses to Mo.
On 12/13/13 1:43 PM, Dong Mo wrote:
> Hi all,
>
> 1.What is "reserve" means here? Does it means that no other traffic can
> flow on the reserved link at the reserved time and I own the reserved
> capacity by my own?
>
By "reserve" if you mean creating the GMOC ticket about your potentially
disruptive experiment, all that does is inform the affected aggregates
that you'll be running an experiment that is potentially disruptive.
There is no actual resource reservation that happens.
When you stitched the link between Utah DDC and U. of Missouri, a VLAN
was set up for you between the two racks and the VLAN capacity was set
to 900 Mbps (the capacity you specified) at the switches the VLAN went
through. All this means is the switches will allow up to 900 Mbps of
traffic on your VLAN. I don't think your VLAN is given any higher
priority and so you are still competing for link bandwidth with other
connections.
> I am asking about this because when I set the capacity of stitched link
> to 900Mbps, what I can really get is only about 200Mbps.
>
> Note that by "get" I mean I use UDP traffic to saturate the link at
> 1Gbps from one site to another but at the receiving end, the perceived
> throughput is only 200Mbps. I know there could be limitation of TCP and
> other protocols, so that 900Mbps cannot be reached use them. But I am
> not using any congestion protocol but only flooding in the network on
> 1G, however, what I can get is only 200Mbps.
>
I don't know why you got only 200 Mbps. It could be something in the
network or something at the end hosts. I think you stitched together
two OpenVZ containers and I don't know if the virtualization layer is
limiting your bandwidth. You might want to get a raw PC at two racks
and run your experiment again. This will tell you if it is the network
or the OS/virtualization that is the bottleneck.
I also suggest starting with a lower bandwidth link (say 500 Mbps) to
see if you get that with raw PCs. You will not need to coordinate with
the GMOC or the aggregate providers to try this out.
> 2. Why I could not write 1000000 at the capacity option in the rspec? It
> seems I can only specify some value smaller than that. Is this a bug for
> stitcher.py or omni?
>
I do not know why your attempt to stitch a 1Gbps link failed at the
Missouri aggregate. It is possible the switch there was unable to
provision a 1Gbps VLAN for you at that site because of others already
having reserved bandwidth there.
Best wishes,
< Vic
Jonathon Duerig
Dec 13, 2013, 4:12:59 PM12/13/13
to geni-...@googlegroups.com, Dong Mo
In this context, 'reserve' means reserve at the aggregate endpoints. I
don't think any reservation happens within Ion. So what this means is that
the physical interface between the rack and Ion will never be
oversubscribed. But you may still get drops between them.
If you want a reserved end-to-end path, then you might be better served
using the nodes on the ProtoGENI backbone within the Utah aggregate.
---
Broad audience or deep message: Pick one.
> --
> GENI Users is a community supported mailing list, so please help by
> responding to questions you know the answer to.
>
> If this is your first time posting a question to this list, please review
> http://groups.geni.net/geni/wiki/GENIExperimenter/CommunityMailingList
> --- You received this message because you are subscribed to the Google Groups
> "GENI Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to geni-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
don't think any reservation happens within Ion. So what this means is that
the physical interface between the rack and Ion will never be
oversubscribed. But you may still get drops between them.
If you want a reserved end-to-end path, then you might be better served
using the nodes on the ProtoGENI backbone within the Utah aggregate.
---
Broad audience or deep message: Pick one.
> GENI Users is a community supported mailing list, so please help by
> responding to questions you know the answer to.
>
> If this is your first time posting a question to this list, please review
> http://groups.geni.net/geni/wiki/GENIExperimenter/CommunityMailingList
> --- You received this message because you are subscribed to the Google Groups
> "GENI Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to geni-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
Dong Mo
Dec 13, 2013, 4:14:34 PM12/13/13
to Jonathon Duerig, geni-...@googlegroups.com
I see. Thanks a lot for the response and actually I do want a little not-so-clean network for my tests!
Thank you so much!
-Mo
-Mo
To unsubscribe from this group and stop receiving emails from it, send an email to geni-users+unsubscribe@googlegroups.com.
Aaron Helsinger
Dec 13, 2013, 4:32:59 PM12/13/13
to geni-...@googlegroups.com, Dong Mo
On 12/13/13 4:02 PM, Vicraj Thomas wrote:
>
>
> > 2. Why I could not write 1000000 at the capacity option in the rspec? It
> > seems I can only specify some value smaller than that. Is this a bug for
> > stitcher.py or omni?
> >
> I do not know why your attempt to stitch a 1Gbps link failed at the Missouri aggregate. It is possible the switch there was unable to provision a 1Gbps VLAN for you at that site because of others already having reserved bandwidth there.
If you mean that the reservation failed, then it may mean that one of the places where you requested that capacity did not have that much capacity available.
Aaron
Reply all
Reply to author
Forward
0 new messages