A buffer sized for about 3 frames worth of data is generally safe enough. You can map with unsynchronized, append, and when the buffer fills you just begin again at the start of the buffer without needing to fence or orphan. I'd still feel safer adding a fence just in case you hit a non-typical frame.

^ Yes! What that guy said! I hate seeing FPS measurements. They totally skew perception of the results.

With those particular numbers I'd just use glBufferSubData and wouldn't even bother.

So I'm wondering what gives, I would think that numbers would be the other way around? I thought that the UNSYNCRONIZED flag was supposed to tell the GPU not to block, where as glBufferSubData does cause a block on the GPU?

That isnt necesarely true. glBufferSubData works by passing the data to the driver, the driver making a copy of it, then returning from the call. Then the driver is free to copy immediately to the GPU, buffer a couple of commands first instead, or use whatever data updating scheme the driver uses.

With glMapBuffer, the driver gives you a pointer to driver's memory space, so no intermediary copy is being made, you just write to the driver's memory.

EDIT: Mother fucking quote blocks, how do they work?

When it comes to fences how would this work? I understand how the actual fence works (I basically stall if the GPU is not finished with its commands)

But how would I know that my fence is valid? Valid in the sense that I am only waiting on the parts of my buffer that I need to wait on.

Or is it something that is automatically done, since I am only mapping a range of my buffer and not the entire thing?

What you're basically doing is using it as a ring buffer. Say you create a buffer big enough to hold 4000 objects. In frame 1 you write 1000 objects into locations 0 to 999. In frame 2 you're drawing another 1000 objects but this time you write them into locations 1000 to 1999, adjusting the parameters of your draw calls accordingly. In frame 3 you draw another 1000 from locations 2000 to 2999. Frame 4 you use 3000 to 3999. When frame 5 comes around you can say with some confidence that the commands you issued in frame 1 have already been processed by the GPU so it's now safe to go back and write to locations 0 to 999 again. Use a fence to ensure that it's safe by blocking until the GPU is ready before you do so, if you wish; otherwise orphan, otherwise choose to live a little dangerously.

Each frame you're appending to a part of the buffer that you absolutely know for certain is not being used for any previously queued-up draw calls: either the fence ensures it, or orphaning ensures it, or enough frames have passed (GPUs typically buffer-up 3 frames; I added one extra in this example for headroom); either way you know it because you haven't issued any draw calls from that part of the buffer yet or the GPU has already finished with calls that you previously did issue from it. That part is perfectly safe to do. What's important is that the fence (or orphaning) isn't necessary every frame; it's only necessary in the frame in which you go back to the start of the buffer and begin again from that point.

A buffer sized for about 3 frames worth of data is generally safe enough. You can map with unsynchronized, append, and when the buffer fills you just begin again at the start of the buffer without needing to fence or orphan. I'd still feel safer adding a fence just in case you hit a non-typical frame.

Never do this without fences! You cant assume a maximum of two frames latency unless you use a fence to enforce it.
You're making the gamble that your users won't be GPU-bottlenecked, and that their driver isn't going to attempt to help by adding extra command buffering, with the wager of you betting graphical corruption against the prize of not having to make a handful of api calls at the end of each frame. That's not a good wager.

The simplest solution it to place a fence at the end of every frame and have the CPU block on the previous frame's fence (max 1 frame latency) or the previous previous frame's fence (max 2 frames latency).

You can then safely size your buffers to be max_size_required_per_frame * (max_latency + 1), and otherwise safely make assumptions about max latency.

[edit]
BTW, many games have done this for a long time, just to put a limit on buffered GPU frames, as more buffering results in more input lag. FPS or "twitchy" games often limit themselves to one frame's latency, which also has the bonus of reducing the memory requirements of your ring buffers.