If you're trying to test 1xGE No Drop Rate and measure circuit delay within 8ms, I would use nuttcp to test bandwidth and iperf2 / mtr to test delay.

I would do the following...

1. Find two linux desktop PCs, if possible (laptops are sometimes acceptable, but you might run into issues with chipset or bus performance at 1GE speeds). You can boot into a Knoppix Live CD, if you don't want a permanent linux install on these boxes
2. Select packet sizes for your test. Since you need voice support on the circuit, you should test streams with smaller frames, such as 128-byte ethernet frames. If I was running the test, I would choose 128, 256, 768 and 1514 byte ethernet frames.
3. Test nuttcp UDP bandwidth performance of your linux PCs connected back to back before shipping one of them 100 miles away. You want to ensure that you can measure 1000 Mbps at various packet sizes. Be sure to account for the Inter-Frame Gap when you calculate expected throughput rates... for instance the best possible throughput you can expect on an untagged gige circuit at a 128-byte average ethernet frame size is 864.9 Mbps.
4. Use iperf2 or mtr to test circuit delay...
5. Pick a test window. I think it's best to test circuits continuously for at least a day... two days to a week are preferable if you need to get a sense for potential oversubscription within your carrier's network.
6. Ship one of the PCs off to the remote site, preconfigured for the IP addressing you need on the link.

Misc thoughts

Other answers have suggested using iperf2 alone; however, it doesn't have CLI options to adjust the UDP packet size. It also tends to demonstrate flaky performance at high speeds under MS Windows.

This Metro Ethernet Forum paper on testing carrier ethernet circuits will help provide a general understanding some of the tradeoffs you take when testing circuits.

If you're trying to test 1xGE No Drop Rate and measure circuit delay within 8ms, I would use nuttcp to test bandwidth and iperf2 / mtr to test delay.

I would do the following...

1. Find two linux desktop PCs, if possible (laptops are sometimes acceptable, but you might run into issues with chipset or bus performance at 1GE speeds). You can boot into a Performance Sonar toolkit CD, if you don't want a permanent linux install on these boxes
2. Select packet sizes for your test. Since you need voice support on the circuit, you should test streams with smaller frames, such as 128-byte ethernet frames. If I was running the test, I would choose 128, 256, 768 and 1514 byte ethernet frames.
3. Test nuttcp UDP bandwidth performance of your linux PCs connected back to back before shipping one of them 100 miles away. You want to ensure that you can measure 1000 Mbps at various packet sizes. Be sure to account for the Inter-Frame Gap when you calculate expected throughput rates... for instance the best possible throughput you can expect on an untagged gige circuit at a 128-byte average ethernet frame size is 864.9 Mbps.
4. Use iperf2 or mtr to test circuit delay...
5. Pick a test window. I think it's best to test circuits continuously for at least a day... two days to a week are preferable if you need to get a sense for potential oversubscription within your carrier's network.
6. Ship one of the PCs off to the remote site, preconfigured for the IP addressing you need on the link.

Misc thoughts

Other answers have suggested using iperf2 alone; however, it doesn't have CLI options to adjust the UDP packet size. It also tends to demonstrate flaky performance at high speeds under MS Windows.

This Metro Ethernet Forum paper on testing carrier ethernet circuits will help provide a general understanding some of the tradeoffs you take when testing circuits.